Forgot to reply-all.

Begin forwarded message:

From: Markus Unterwaditzer 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

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

Anthony

On Fri, Sep 20, 2019 at 7:16 AM Philippe Prados 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 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/