boolean over multiple variables

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:hjnmdl$166s$1 at digitalmars.com...
> Nick Sabalausky:
>> Aside from that being how Python does it, why do you see that as 
>> preferable?
>
> Because:
> 1) linear searches in an array are damn common. I don't remember the 
> results of my benchmarks, but until your integer arrays is quite longer 
> than 30-50 items, performing a linear search is faster than a lookup in an 
> AA, on DMD. On Tango this number is probably 70% higher
> 1b) In Python if you perform a "foo" in "barfoo" the language doesn't 
> perform a linear search, it uses a much smarter search that has a 
> complexity lower than the product of the two lengths, using a custom 
> algorithm. So in D you can use the same syntax to search for 
> substrings/subarrays. Where such smarter search is not possible, D can use 
> a naive search.
> 2) It's really handy. I use isIn(item, items) to search on arrays in D, 
> but having a item in items is nicer.
> 3) You can use the same syntax to search into anything that's lazily 
> iterable too (a Range). This is very handy.
>

I don't see how any of that argues against the idea of making "in" always 
operate on the elements and having a different method for checking the keys. 
Can you be more clear on that point?

>
>> So having a single syntax work on the outputs for
>> regular arrays, but then on the inputs for AAs, seems highly inconsistent
>> and error-prone to me.
>
> I have followed many Python newbies personally, I am following the Python 
> newsgroups, and I have programmed for years in Python, and while I have 
> seen many different kinds of bugs, I have not seen a significant amount of 
> bugs in this. Python programmers just learn that dicts and lists are a 
> little different in this regard. At the same way they learn that a set and 
> a dict are different data structures, with different capabilities and 
> usages.
>
> Why don't you start using Python, I think in 5 days you can tell that's 
> easy to not confuse the following usages:
> 5 in {5:1, 2:2, 5:3}
> 5 in [1, 2, 5]
> "5" in "125"
> "25" in "125"
>

I'm sure I could, but that doesn't change anything. I've used a lot of 
languages with lots of poorly-designed features, and I've always been able 
to deal with the problems in those poorly-designed features. But just 
because I can get used to dealing with them doesn't mean they're not 
poorly-designed or that I wouldn't prefer or be better off with something 
different. (And for the record, I have used a bit of Python here and there. 
Still not particularly happy with it.)

Ex: All of us get along just fine with "if(is())", but it's still widely 
considered a design in need of fixing.
Ex: C/C++ programmers get by with its system of #include and header files 
just fine. But obviously it still had plenty of worthwhile room for 
improvement.