Nick Sabalausky:

>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.<

I have already done my best with those words, so... :-)

AA elements are its keys, that are a set. In Python3 if you have a dict named 
foo, then foo.keys() returns something that's very like a set view. And foo 
itself acts like a set (you can iterate on the items of this set, etc).
The values are the things associated to that set of elements.
So maybe your are seeing associative arrays as arrays, while in Python they are 
seen as sets with associated values :-) And seeing them as a special kind of 
set is better, because it gives you some handy syntax back, that I have shown 
you. Maybe we can change their name in D and call them "Associative Sets" :o)


>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.<

What kind of problems has caused the "in" in your Python programs?


>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.<

You can find several people (me, for example) that think of those are warts or 
badly designed things (or things designed for much less powerful computers, 
#include). While if you take a sample of 50000 Python and Ruby programmers you 
will not find many of them that think that "in" is badly designed  (or not very 
handy) in Python. If you search on the web you can find pages that list some 
Python warts, you will not find "in" among them. You can find things like:
class Foo:
  def __init__(self, x=[]): ...
Where people say that [] causes problems or they don't like that "self" as 
first argument, etc.

Probably I am not going to change your mind (and probably Walter's, he probably 
doesn't even reads the d.learn group), so this discussion is probably mostly 
academic :-)

Bye,
bearophile

Reply via email to