Fwd: Re: Discussions-To PEP-0604: Complementary syntax for Union[] and Optional[]
Forgot to reply-all.
Begin forwarded message:
From: Markus Unterwaditzer <markus@unterwaditzer.net> Subject: Re: [Typing-sig] Re: Discussions-To PEP-0604: Complementary syntax for Union[] and Optional[] Date: 20. September 2019 at 22:37:33 CEST To: Anthony Sottile <asottile@umich.edu>
In a hypothetical A[T] I am not thinking of the T. I am thinking of A.
Let's say you have some old library that defines an Array class. For some reason that library implements getitem on its metaclass. Now you want to define typesheds that are generic over the Array's items (Array[T]). You're screwed.
Luckily the workaround is easy (I believe) using type hint comments or the string-based syntax.
On 20.09.2019, at 22:11, Anthony Sottile <asottile@umich.edu> wrote:
generic of T where T defines __getitem__ is not a problem, I don't see your point
On Fri, Sep 20, 2019, 10:07 PM Markus Unterwaditzer <markus@unterwaditzer.net> wrote: I am thinking of code that has been written long before typing existed, and overloads __getitem__ with something else. Now if one had to define stub/typeshed files for that code and had to use generics, it would conflict.
On 20.09.2019, at 21:51, Anthony Sottile <asottile@umich.edu> wrote:
how so? I don't see how this interferes at all unless the metaclass is trying to implement genericism itself
Anthony
On Fri, Sep 20, 2019, 9:48 PM Markus Unterwaditzer <markus@unterwaditzer.net> wrote: Code that defines dunder methods on meta classes is likely already broken due to use of __getitem__ for generics. So there exists a precedent for not caring about such code.
On September 20, 2019 6:04:04 PM GMT+02:00, Anthony Sottile <asottile@umich.edu> wrote: I'd like to see a backward compatibility concern highlighted in the PEP -- given it's possible (and likely?) that some metaclass in the wild already defines `__or__` or `__invert__` semantics
class M(type): ... def __or__(self, other): return self ... class C(metaclass=M): pass ... C | int <class '__main__.C'>
Anthony
On Fri, Sep 20, 2019 at 7:16 AM Philippe Prados <philippe.prados@gmail.com> wrote: The Resolving type hints at runtime says: “For code which uses annotations for other purposes, a regular eval(ann, globals, locals) call is enough to resolve the annotation.”. Without add a new operator `__or__` in type `type`, it’s not possible to resolve type hints at runtime.
from __future__ import annotations def foo() -> int | str: pass ... eval(foo.__annotations__['return']) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for |: 'type' and 'type'
Le ven. 20 sept. 2019 à 15:35, Sebastian Rittau <srittau@rittau.biz> a écrit : Am 20.09.19 um 14:49 schrieb Chris Angelico:
Both "int or str" and "str?" have the problem that they don't work under existing Python syntax, so they would be far greater changes. The definition of the "or" operator is baked into the language, but the "|" operator can have its semantics defined by the objects on either side.
"or" works with "from __future__ import annotations", which is a fine limitation in my opinion.
- Sebastian _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
right but mypy/friends wouldn't consider that Generic so it doesn't matter, whereas existing piping / negating classes would be conflicting with the proposal On Fri, Sep 20, 2019, 10:38 PM Markus Unterwaditzer < markus@unterwaditzer.net> wrote:
Forgot to reply-all.
Begin forwarded message:
*From: *Markus Unterwaditzer <markus@unterwaditzer.net> *Subject: **Re: [Typing-sig] Re: Discussions-To PEP-0604: Complementary syntax for Union[] and Optional[]* *Date: *20. September 2019 at 22:37:33 CEST *To: *Anthony Sottile <asottile@umich.edu>
In a hypothetical A[T] I am not thinking of the T. I am thinking of A.
Let's say you have some old library that defines an Array class. For some reason that library implements getitem on its metaclass. Now you want to define typesheds that are generic over the Array's items (Array[T]). You're screwed.
Luckily the workaround is easy (I believe) using type hint comments or the string-based syntax.
On 20.09.2019, at 22:11, Anthony Sottile <asottile@umich.edu> wrote:
generic of T where T defines __getitem__ is not a problem, I don't see your point
On Fri, Sep 20, 2019, 10:07 PM Markus Unterwaditzer < markus@unterwaditzer.net> wrote: I am thinking of code that has been written long before typing existed, and overloads __getitem__ with something else. Now if one had to define stub/typeshed files for that code and had to use generics, it would conflict.
On 20.09.2019, at 21:51, Anthony Sottile <asottile@umich.edu> wrote:
how so? I don't see how this interferes at all unless the metaclass is trying to implement genericism itself
Anthony
On Fri, Sep 20, 2019, 9:48 PM Markus Unterwaditzer < markus@unterwaditzer.net> wrote: Code that defines dunder methods on meta classes is likely already broken due to use of __getitem__ for generics. So there exists a precedent for not caring about such code.
On September 20, 2019 6:04:04 PM GMT+02:00, Anthony Sottile < asottile@umich.edu> wrote: I'd like to see a backward compatibility concern highlighted in the PEP -- given it's possible (and likely?) that some metaclass in the wild already defines `__or__` or `__invert__` semantics
class M(type):
... def __or__(self, other): return self ...
class C(metaclass=M): pass
...
C | int
<class '__main__.C'>
Anthony
On Fri, Sep 20, 2019 at 7:16 AM Philippe Prados <philippe.prados@gmail.com> wrote: The Resolving type hints at runtime says: “For code which uses annotations for other purposes, a regular eval(ann, globals, locals) call is enough to resolve the annotation.”. Without add a new operator `__or__` in type `type`, it’s not possible to resolve type hints at runtime.
from __future__ import annotations def foo() -> int | str: pass
...
eval(foo.__annotations__['return'])
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for |: 'type' and 'type'
Le ven. 20 sept. 2019 à 15:35, Sebastian Rittau <srittau@rittau.biz> a écrit : Am 20.09.19 um 14:49 schrieb Chris Angelico:
Both "int or str" and "str?" have the problem that they don't work under existing Python syntax, so they would be far greater changes. The definition of the "or" operator is baked into the language, but the "|" operator can have its semantics defined by the objects on either side.
"or" works with "from __future__ import annotations", which is a fine limitation in my opinion.
- Sebastian _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
I am really confused. The issue I am talking about is not that mypy would see a generic when I don't want it to see one, the issue is that I cannot define stubs for this type that use generics. So it sees less generics I'd like it to see, not more. On September 20, 2019 10:40:55 PM GMT+02:00, Anthony Sottile <asottile@umich.edu> wrote:
right but mypy/friends wouldn't consider that Generic so it doesn't matter, whereas existing piping / negating classes would be conflicting with the proposal
On Fri, Sep 20, 2019, 10:38 PM Markus Unterwaditzer < markus@unterwaditzer.net> wrote:
Forgot to reply-all.
Begin forwarded message:
*From: *Markus Unterwaditzer <markus@unterwaditzer.net> *Subject: **Re: [Typing-sig] Re: Discussions-To PEP-0604: Complementary syntax for Union[] and Optional[]* *Date: *20. September 2019 at 22:37:33 CEST *To: *Anthony Sottile <asottile@umich.edu>
In a hypothetical A[T] I am not thinking of the T. I am thinking of A.
Let's say you have some old library that defines an Array class. For some reason that library implements getitem on its metaclass. Now you want to define typesheds that are generic over the Array's items (Array[T]). You're screwed.
Luckily the workaround is easy (I believe) using type hint comments or the string-based syntax.
On 20.09.2019, at 22:11, Anthony Sottile <asottile@umich.edu> wrote:
generic of T where T defines __getitem__ is not a problem, I don't see your point
On Fri, Sep 20, 2019, 10:07 PM Markus Unterwaditzer < markus@unterwaditzer.net> wrote: I am thinking of code that has been written long before typing existed, and overloads __getitem__ with something else. Now if one had to define stub/typeshed files for that code and had to use generics, it would conflict.
On 20.09.2019, at 21:51, Anthony Sottile <asottile@umich.edu> wrote:
how so? I don't see how this interferes at all unless the metaclass is trying to implement genericism itself
Anthony
On Fri, Sep 20, 2019, 9:48 PM Markus Unterwaditzer < markus@unterwaditzer.net> wrote: Code that defines dunder methods on meta classes is likely already broken due to use of __getitem__ for generics. So there exists a precedent for not caring about such code.
On September 20, 2019 6:04:04 PM GMT+02:00, Anthony Sottile < asottile@umich.edu> wrote: I'd like to see a backward compatibility concern highlighted in the PEP -- given it's possible (and likely?) that some metaclass in the wild already defines `__or__` or `__invert__` semantics
class M(type):
... def __or__(self, other): return self ...
class C(metaclass=M): pass
...
C | int
<class '__main__.C'>
Anthony
On Fri, Sep 20, 2019 at 7:16 AM Philippe Prados <philippe.prados@gmail.com> wrote: The Resolving type hints at runtime says: “For code which uses annotations for other purposes, a regular eval(ann, globals, locals) call is enough to resolve the annotation.”. Without add a new operator `__or__` in type `type`, it’s not possible to resolve type hints at runtime.
from __future__ import annotations def foo() -> int | str: pass
...
eval(foo.__annotations__['return'])
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for |: 'type' and 'type'
Le ven. 20 sept. 2019 à 15:35, Sebastian Rittau <srittau@rittau.biz> a écrit : Am 20.09.19 um 14:49 schrieb Chris Angelico:
Both "int or str" and "str?" have the problem that they don't work under existing Python syntax, so they would be far greater changes. The definition of the "or" operator is baked into the language, but the "|" operator can have its semantics defined by the objects on either side.
"or" works with "from __future__ import annotations", which is a fine limitation in my opinion.
- Sebastian _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
my point is that it's very unlikely that a class would define __getitem__ *and* be generic, but it's much more likely that a class defines either __invert__ or __or__ (which doesn't also depend on the caveat of it being generic) and would be utterly incompatible with type unioning / optional-ing Anthony On Fri, Sep 20, 2019 at 1:50 PM Markus Unterwaditzer <markus@unterwaditzer.net> wrote:
I am really confused. The issue I am talking about is not that mypy would see a generic when I don't want it to see one, the issue is that I cannot define stubs for this type that use generics. So it sees less generics I'd like it to see, not more.
On September 20, 2019 10:40:55 PM GMT+02:00, Anthony Sottile <asottile@umich.edu> wrote:
right but mypy/friends wouldn't consider that Generic so it doesn't matter, whereas existing piping / negating classes would be conflicting with the proposal
On Fri, Sep 20, 2019, 10:38 PM Markus Unterwaditzer <markus@unterwaditzer.net> wrote:
Forgot to reply-all.
Begin forwarded message:
From: Markus Unterwaditzer <markus@unterwaditzer.net> Subject: Re: [Typing-sig] Re: Discussions-To PEP-0604: Complementary syntax for Union[] and Optional[] Date: 20. September 2019 at 22:37:33 CEST To: Anthony Sottile <asottile@umich.edu>
In a hypothetical A[T] I am not thinking of the T. I am thinking of A.
Let's say you have some old library that defines an Array class. For some reason that library implements getitem on its metaclass. Now you want to define typesheds that are generic over the Array's items (Array[T]). You're screwed.
Luckily the workaround is easy (I believe) using type hint comments or the string-based syntax.
On 20.09.2019, at 22:11, Anthony Sottile <asottile@umich.edu> wrote:
generic of T where T defines __getitem__ is not a problem, I don't see your point
On Fri, Sep 20, 2019, 10:07 PM Markus Unterwaditzer <markus@unterwaditzer.net> wrote: I am thinking of code that has been written long before typing existed, and overloads __getitem__ with something else. Now if one had to define stub/typeshed files for that code and had to use generics, it would conflict.
On 20.09.2019, at 21:51, Anthony Sottile <asottile@umich.edu> wrote:
how so? I don't see how this interferes at all unless the metaclass is trying to implement genericism itself
Anthony
On Fri, Sep 20, 2019, 9:48 PM Markus Unterwaditzer <markus@unterwaditzer.net> wrote: Code that defines dunder methods on meta classes is likely already broken due to use of __getitem__ for generics. So there exists a precedent for not caring about such code.
On September 20, 2019 6:04:04 PM GMT+02:00, Anthony Sottile <asottile@umich.edu> wrote: I'd like to see a backward compatibility concern highlighted in the PEP -- given it's possible (and likely?) that some metaclass in the wild already defines `__or__` or `__invert__` semantics
class M(type):
... def __or__(self, other): return self ...
class C(metaclass=M): pass
...
C | int
<class '__main__.C'>
Anthony
On Fri, Sep 20, 2019 at 7:16 AM Philippe Prados <philippe.prados@gmail.com> wrote: The Resolving type hints at runtime says: “For code which uses annotations for other purposes, a regular eval(ann, globals, locals) call is enough to resolve the annotation.”. Without add a new operator `__or__` in type `type`, it’s not possible to resolve type hints at runtime.
from __future__ import annotations def foo() -> int | str: pass
...
eval(foo.__annotations__['return'])
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for |: 'type' and 'type'
Le ven. 20 sept. 2019 à 15:35, Sebastian Rittau <srittau@rittau.biz> a écrit : Am 20.09.19 um 14:49 schrieb Chris Angelico:
Both "int or str" and "str?" have the problem that they don't work under existing Python syntax, so they would be far greater changes. The definition of the "or" operator is baked into the language, but the "|" operator can have its semantics defined by the objects on either side.
"or" works with "from __future__ import annotations", which is a fine limitation in my opinion.
- Sebastian _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
participants (2)
-
Anthony Sottile -
Markus Unterwaditzer