On Thu, Mar 02, 2017 at 04:23:08AM +0100, Jürgen A. Erhard wrote:
The OP seems to be proposing that we reflect this identity between types and sets in Python by spelling "isinstance(obj, T)" as "obj in T" and "issubclass(S, T)" as "S <= T". This proposal has some solid theory behind it and I don't think it would be hard to implement, but it doesn't seem like a particularly useful change to me. It wouldn't really enable anything we can't do now, and it may be confusing to people reading code that "obj in list" does something completely different from "obj in list()".
So? Compare to "fn" vs "fn()" now. Yes, some people are confused. So what. You *do* have to learn things.
I don't understand what this comparison is supposed to show. `fn` is a name. `fn()` does a function call on whatever object is bound to `fn`. How is that relevant to the question of adding a completely separate set-like interface to isinstance and issubclass?
And "enable anything we can't do now". That argument was used any number of times on this list, and even before this very list even existed.
It has been used many times. That is because it is a GOOD argument. We don't just add every single random feature that people can think of. ("Hey, wouldn't it be AWESOME if Class*str returned a list of class methods that contained the string in their name???") The new functionality, spelling or syntax has to add some benefit to make up for the extra cost: - the cost to develop this new feature or syntax; - the cost to write new tests for this feature; - the cost to document it; - the cost to documentation in books and the web that are now obsolete or incorrect; - the cost for people to learn this feature; - the cost for people to decide whether to use the old or the new spelling; and so forth.
Still, we got decorators (they don't enable anything we couldn't do without them, and we actually can still do what they do without using them).
Indeed, but you are missing that decorator syntax brings some VERY important benefits that are a clear win over the old way: @decorate def spam(): ... versus def spam(): ... spam = decorate(spam) The decorator syntax avoids writing the function name three times, but more importantly, it puts the decoration right at the start of the function, next to the signature, where it is more obvious and easier to see, instead of way down the end, which might be many lines or even pages away. That's a very big win that makes decorator syntax the One Obvious Way to decorate functions and classes. Compare to the OP's suggestion: 23 in int This doesn't even make sense unless you have been exposed to a very small subset of theoretical computer science which treats classes as sets and instances as elements of those sets. To everyone else, especially those with a background in "ordinary" OOP, it looks like nonsense. (Personally, I'm a bit dubious about conflating is-a and element-of operations in this way, it feels like a category mistake to me, but for the sake of the argument I'll accept it.) So the benefit applies only to a tiny subset of users, but the cost is carried by everyone. -- Steve