Since you mentioned my name, let me explain my current position on how to spell "optional".

- We've had a lot of feedback from mypy users who were confused by Optional[T] and thought this was needed for "optional" function arguments (i.e. those that have a default).

- Another situation where people have been confused Optional is in TypedDict, where we wanted to have a way to say "this key may be present or absent" (in the end we couldn't find a good keyword for this so we went with "total=<bool>" for the entire dict).

- It would probably have been less confusing if it had been called "nullable" (or "noneable"? Ruby's Sorbet type system calls it "nilable").

- In TypeScript you just write "int | None", and that looks readable enough to me -- and perfectly unambiguous.

So my preference would be to drop the "~" proposal (or aspirations for "?") and instead just write "int | None".

IIRC at last Friday's Bay Area typing meetup there was general agreement with this sentiment.

--Guido

On Tue, Sep 24, 2019 at 9:38 AM Philippe Prados <philippe.prados@gmail.com> wrote:
My point on the operator __invert__.
  • The old style 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 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

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


--
--Guido van Rossum (python.org/~guido)
Pronouns: he/him/his (why is my pronoun here?)