My point on the operator __invert__. - The old style string formatting <https://docs.python.org/2/library/stdtypes.html#string-formatting> use '%', the modulo operator. But in this context, the user can not make a mistake. I think, it is the same for toto:~int - The operator __invert__ (~) is not the best, like '?', but '?' is use by IPython and at time, Python has no operator for that. - This operator is not bad, because '~' is very little used by normal user and the usage of tilde <https://www.thecut.com/article/why-the-internet-tilde-is-our-most-perfect-to...> is compatible with this proposition, as Guido van Rossum reminded - Why the typing propose the class Optional[T] ? I think it's because Union[T,None] is not exactly the same in the mind of the user. Optional say "Something or nothing". Union say "This type or this other type". I think the same arguments to accept the class Optional can be used to accept the operator __invert__. Philippe Le lun. 23 sept. 2019 à 14:38, Anthony Sottile <asottile@umich.edu> a écrit :
The code "works" in that it doesn't crash, but it may result in unintended import-time side-effects when an annotation was requested (an example I've seen of `|` in the wild on a metaclass is a subprocess piping library) -- and you don't get the type annotation either you end up with the type's `|` or `~` being used so `__annotations__` is wrong
On Sun, Sep 22, 2019 at 11:46 PM Philippe Prados < philippe.prados@gmail.com> wrote:
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 <https://github.com/pprados/peps/blob/pep-0604/pep-0604.rst>
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/