Re: [Python-ideas] add __contains__ into the "type" object

[Pavol Lisy]

On 3/2/17, 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)
>
> 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

:)

Problem of Russel paradox was that set was defined intuitively in that time.

And it is why **class**, was introduced in set theory then! :)

In set theory you could ask if x member of set or x is member of class
and difference between set and class is just that set is not same as
class. (class is some intuitively defined concept just to avoid
paradoxes like Russel's)

And python does not implement platonism
(https://en.wikipedia.org/wiki/Philosophy_of_mathematics#Platonism) -
object doesn't exists until they are created.

class int is not infinite in its actuality. (Does not occupy infinite memory)

So I think that print(R in R) would print True. Because in the time
set is in creation process this object (set) is not member of that set
so it would be added to that set.

Or maybe it will return False if this incomplete set is not evaluated
in process of its creation.

It is matter of implementation, but it could be perfectly deterministic.

So maybe Russel had to "implement" GIL in mathematics ;)

In current python you could ask about "membership" (operator in) where
object is not set:

if 3 in itertools.count():  # this is ok
type(itertools.count())  # this is ok
else:
set(itertools.count())   # I don't approve this :P

python set is not mathematics set too:

a = set()
a.add(a)  # TypeError: unhashable type: 'set'

I am -1 about proposal in this moment. I probably understand
motivation but I don't see yet that this change could bring enough
goodness.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add __contains__ into the "type" object

[Ethan Furman]

-1.

It is already possible to specify what

  inst in cls

means by using a metaclass.  For example:

  class Color(enum.Enum):
 RED = 1
 GREEN = 2
 BLUE = 3

  some_var = Color.GREEN
  some_var in Color  # True
  some_var in enum.Enum  # False

Containment != isinstance()

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add __contains__ into the "type" object

[Ryan Hiebert]

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

Re: [Python-ideas] add __contains__ into the "type" object

[Chris Angelico]

On Fri, Mar 3, 2017 at 12:44 AM, Steven D'Aprano  wrote:
> 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.)

I've seen languages in which types can be the RHO of 'is', so this
would look like:

23 is int

Obviously that depends on types not themselves being first-class
objects, but it makes a lot more sense than a containment check.

But I'm trying to think how frequently I do *any* type checking in
production code. It's not often. It doesn't need syntax.
isinstance(23, int) works fine.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add __contains__ into the "type" object

[Steven D'Aprano]

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/

Re: [Python-ideas] add __contains__ into the "type" object

[Clint Hepner]

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

Re: [Python-ideas] add __contains__ into the "type" object

[אלעזר]

This suggestion is really problematic IMHO.

"isinstance" is a nominal check. I can't ask "isinstance(x, Callable[int,
int])" because that would imply solving the halting problem. so
"isinstance(x, Y)" does not mean "is it true that x is an element of the
type Y" but rather "is it true that x was created by a constructor of some
superclass of Y". It is not a type-theoretic question but a question of
origin and intent.

With regard to readability, this will be completely confusing for me. "in"
is a question about inclusion in a collection, not some set-theoretic
inclusion. Otherwise we should also as "x in f" as an equivalent to "not
not f(x)", as is in set theory.

Elazar
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add __contains__ into the "type" object

[Stephan Houben]

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

Re: [Python-ideas] add __contains__ into the "type" object

[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/

Re: [Python-ideas] add __contains__ into the "type" object

[Jürgen A . Erhard]

On Tue, Feb 28, 2017 at 03:35:31PM -0800, 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()".

So?  Compare to "fn" vs "fn()" now.  Yes, some people are confused.
So what.  You *do* have to learn things.

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

"isinstane" and "issubclass" are explicit!  Yay!... and decorators are
"implicit", and wouldn't you know it, they *do* confuse people.

I'm +.05 (and no, that's not because I finally see an idea of  that I actually think has some merit).  Maybe
even +1, given that isinstance(obj, class) is rather bulky.  Okay,
make that a +1.

Bye, J

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add __contains__ into the "type" object

[Eric V. Smith]

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.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add __contains__ into the "type" object

[Jelle Zijlstra]

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

> "is-a" tests are not the same as "in" tests. They are completely
> unrelated comparisons.
>
> http://www.w3resource.com/java-tutorial/inheritance-composition-relationship.php
>
> The Wikipedia page on is-a is terribly complicated, but folks may get
> something from it:
>
> https://en.wikipedia.org/wiki/Is-a
>
>
>
> --
> 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/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/