boolean over multiple variables

[bearophile]

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