Michel Fortin:
> Are you sure the 'not in' operator in the Python algorithm you liked to
> works like D's '!in'? It seems to me like it's searching for the
> absence of a substring.
In Python "in" calls the standard method __contains__() of an object.
__contains__ performs hash search in an associative array and a linear search
in a list, tuple, array, etc, or in a lazily generated sequence:
>>> txt = "How are you?"
>>> "are" in txt
True
>>> seq = [1, 2, 3, 4]
>>> 3 in seq
True
>>> adict = {1:2, 3:4}
>>> 3 in adict
True
>>> from itertools import count
>>> evens = (2*i for i in count())
>>> 16 in evens
True
In Python there are no chars, there are just strings, a char is a string of
length 1, so the __contains__ performs a substring search (with many
optimizations, so if you look for a substring of length 1 it's faster, etc).
>In D 'in' and '!in' only look for one element.<
Currently In D 'in' and '!in' only look for one element inside an AA, or calls
the opIn/opIn_r if present.
> I agree that it'd be handy to have 'in' and '!in' work with arrays,
> especially with array literals:
> if (x in [1,2,5,6,10])
> do(something);
> Perhaps this syntax could be allowed but only for array literals.
No silly special cases please. If it works for arrays, it works for all arrays.
Otherwise nothing is better. Special cases increase complexity and kill
languages with a death by a thousand cuts.
>The reason being that array literals are usually short so a linear search
>wouldn't be too bad.<
"bad" is meaningless. If I have to perform a single linear search in a long
array I don't want a nanny compiler to tell me that's a bad thing. Not even
Python does it.
>Moreover, an array literal being a literal, it's easy for the compiler to
>optimize things; you're not constrained to a linear search.<
A linear search on a small array is quite quick in a low level language like D,
faster than a badly implemeted hash search (see LDC+Tango, the breaking point
for an array of integers is about 15 numbers. DMD is better here).
Bye,
bearophile
