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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
