I checked the impacts with the meta-classes.

>>> class M(type): ... def __or__(self,other): return "Hello" ... def __invert__(self): return "World" ... >>> class C(metaclass=M):pass ... >>> C | int 'Hello' >>> ~C 'Word' >>> int | C typing.Union[int, __main__.C] >>> Union[C,int] typing.Union[__main__.C, int] >>>

Because type is the top level metaclass, there is no impact of the current code. The user can continue to use the old syntax with Union, to resolve ambiguities.

I add this in the new draft of the PEP

Philippe

Le ven. 20 sept. 2019 à 22:12, Anthony Sottile <asottile@umich.edu> a écrit :

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/