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/
Anthony Sottile
Markus Unterwaditzer