The requirement of having a PEP sponsor is to make sure that poorly thought-out proposals are stopped with minimal waste of resources. Your proposal, even though I am not particularly in favor of it, deserves to be a discussion to have. (For example, it seems that TypeScript is surviving even though it also has this problem of how best to write `Optional[Union[...]]`.)

So if you can't find someone else to sponsor it, I will, even though when it comes down to accepting it I would probably recommend that the SC reject it. Even that would be useful, since then we can point to the rejected PEP when the idea is brought up again. :-)

Finally -- wouldn't we need to have a new dunder method/protocol so the operator can be overloaded for other functionality?

On Wed, Sep 9, 2020 at 3:12 PM Maggie Moss <maggiemoss@fb.com> wrote:
Thanks for the feedback. 

One additional question here: Would anyone like to sponsor this PEP?


Thanks, 
Maggie

From: Guido van Rossum <guido@python.org>
Sent: Thursday, September 3, 2020 3:18 PM
To: Maggie Moss <maggiemoss@fb.com>
Cc: typing-sig@python.org <typing-sig@python.org>
Subject: Re: [Typing-sig] Update: Work on Optional Syntax PEP
 
Wow, you've been busy! (I know I still owe you a review on the PEP 604 implementation. It's on my TODO list. :-)

My main observation at this point is that introducing a new token means that there is no way to use this in code that has to be backwards compatible with Python 3.9 and before (assuming you could get it into 3.10). This is different for PEP 604's `|` operator, which can be used in Python 3.7+ as long as the `from __future__ import annotations` magic import is used to avoid runtime errors on things like `int | str`. The `|` operator could also be used in typeshed, since it is valid Python 3.7 syntax. (While I don't know of any type checkers that currently support it yet, supporting it would not require changes to the Python *parser* -- at least typed_ast can handle it without changes.)

However, this shouldn't be a big strike against the proposal. In a few short years Python 3.10 will be the oldest version supported and all will be well.

Another concern I have is that we already have two ways to spell "optional": `Optional[T]` and `T | None`.

Finally, IMO the argument against `Optional[T]` is stronger than the argument against `T | None`. (But your point that 7% of annotations use Optional is well taken.)

--Guido



On Thu, Sep 3, 2020 at 12:04 PM None via Typing-sig <typing-sig@python.org> wrote:
Hi there,

Recently I have been working on an implementation for PEP 604 (https://www.python.org/dev/peps/pep-0604/). While working on this, I started reviewing and exploring what new Optional syntax would look like in the Python language.

I've written a rough draft of a PEP and wanted to present it to this email list before submitting a PR. I know this is a topic that has been discussed in many settings (Github issues, in person typing meetups, etc. )previously, and wanted to solicit feedback here first. Let me know if submitting a PR would be a better way to gauge sentiment and feedback on this proposal.

Draft Proposal (branch compare): https://github.com/python/peps/compare/master...MaggieMoss:optional-syntax-pep
Gist: https://gist.github.com/MaggieMoss/c848cb3a581979f445d075c15629c950

Thanks again,
Maggie
_______________________________________________
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/
Member address: guido@python.org


--
--Guido van Rossum (python.org/~guido)


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