On 2/28/2017 6:35 PM, Jelle Zijlstra wrote:

2017-02-28 15:12 GMT-08:00 Steven D'Aprano :

...

On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote:

...

where we use types? almost: isinstance(obj, T); # issubclass(S, T);

Note that TYPE is SET;

What does that mean? I don't understand.

...

if we add __contains__ and __le__ into "type", then things become: obj in T;

But obj is **not** in T, since T is a type, not a container.

But in type theory, types are sets in some sense. For example, the bool type is the set {True, False}, and the int type is the infinite set {..., -1, 0, 1, ...}. Similarly, typing.py has a Union type: Union[A, B] is the union of the types A and B. Subclasses are subsets of their parent classes, because their set of possible values is a subset of the possible values of their parent class.

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()".

Also, you go from the easy to google "python issubclass" to ... ? Syntax is hard to search for. Eric.

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

By itself, I don't see using the ``in`` syntax to check for ``instanceof`` as a big benefit, given the overhead of learning that new concept. However, given in the light of a bigger concept, I think it may make more sense. If we accept that it may be desirable to work with types as set-like objects, apart from (in most cases) iteration, then some other shorthands become reasonable too. Other set operators, such as:: list <= object # issubclass(list, object) Plus the other obvious comparisons. Other set operators can be used for typing:: list | set # same or similar to typing.Union[list, set] mixin1 & mixin2 # Represents classes that inherit from mixin1 and mixin2 When we bring typing into it, it would be cool if those resultant values also were able to do instance and subclass checks. They currently raise an error, but I think it would be possible to do if this were all built into ``type``. And, of course, if we're bringing typing to ``type``, we can replace things like ``typing.List[int]`` with ``list[int]``, and putting those directly into signatures. I think it would be somewhat odd to bring in *some* of the set operators to types, but leave off ``__contains__`` and inequality comparisons. This is not a proposal of all of this, just pointing out that there are further applications to this concept. At least in the case of the typing examples, I think that there are some simplifications to be had by thinking this way. Reasons against also exist, of course, but like everything it's a trade-off to consider. I have a repo that starts some of this, though it's currently broken due to lack of love in the middle of a refactor. I haven't tried to add any typing stuff, but that seems like an obvious extension. I wouldn't expect type checkers to work with a 3rd party module like this, but it could help demonstrate the ideas. https://github.com/ryanhiebert/typeset If anyone is interested enough to help flesh out this proof of concept, I'd be grateful for some collaboration, or being let know of other work like it.

A crucial difference between a set and a type is that you cannot explicitly iterate over the elements of a type, so while we could implement x in int to do something useful, we cannot make for x in int: print(x) Because if we could, we could implement Russell's paradox in Python: R = set(x for x in object if x not in x) print(R in R) Bottom line: a set is not a type, even in mathematics. Stephan 2017-03-02 5:38 GMT+01:00 Pavol Lisy :

On 3/1/17, Steven D'Aprano wrote:

...

On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote:

...

where we use types? almost: isinstance(obj, T); # issubclass(S, T);

Note that TYPE is SET;

What does that mean? I don't understand.

Maybe she/he wants to say that it is natural to see class as a collection (at least in set theory https://en.wikipedia.org/wiki/Class_(set_theory) ) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 2017 Mar 2 , at 2:53 a, Stephan Houben wrote:

A crucial difference between a set and a type is that you cannot explicitly iterate over the elements of a type, so while we could implement

x in int

to do something useful, we cannot make

for x in int: print(x)

__contains__ was introduced to provide a more efficient test than to simply iterate over the elements one by one. I don’t see why something has to be iterable in order to implement __contains__, though. class PositiveInts(int): def __contains__(self, x): return x > 0 N = PostiveInts()

Because if we could, we could implement Russell's paradox in Python:

R = set(x for x in object if x not in x)

print(R in R)

object is not the equivalent of the paradoxical set of all sets. It’s closer to the set of all valid Python values. That includes all valid Python set values, but a Python set is not mathematical set; it’s a *finite* collection of *hashable* values.