On Wed, May 6, 2020 at 1:03 PM Guido van Rossum
Good question.
In early revisions of PEP 484 you could write
def foo(a: int = None) -> ...
and it would imply that the type of 'a' was really Optional[int].
After several years of practice we decided to *remove* this automatic optionalization because it was widely misunderstood and/or confusing for users. For the whole discussion, see https://github.com/python/typing/issues/275. (Also, PEP 484 still mentions it -- "A past version of this PEP allowed ...")
In fact, mypy still defaults to this behavior, and you have to request the new, stricter PEP 484 behavior with `--no-implied-optional`.
Thanks for these pointers to the history of the issue, Guido.
Maybe we could satisfy both sides if the notation for Optional[X] was truly short, like ?X or -X. But that has its own issues -- none of the existing unary operators (+X, -X, ~X) really satisfies, and ?X would require a syntax change (and would forever fix the meaning of one of the last ASCII punctuation characters that has no meaning in Python -- $ being the other one).
I don't think ~X is too bad, if we want to preserve ? for future uses. I also like !X because ! suggests "beware!"—although it would require deeper changes in the language. The past proposals I've seen using ? have to do with handling None or missing attributes, so maybe ?X is the way to go after all—if those needs can be reconciled. Given that the status quo is workable, maybe we can come back to this issue when another proposal for using ? with attributes comes around, to try and solve both problems in a way that looks consistent.
Finally, I wish the whole term "optional" would go away, because of the endless confusion with optional parameters and optional dict keys -- in these contexts the word is widely used to mean "may or may not be present", without implying that the type may include None.
I'd prefer Maybe[x], but I guess that ship has sailed...
Cheers,
Luciano
On Wed, May 6, 2020 at 1:03 PM Guido van Rossum
Good question.
In early revisions of PEP 484 you could write
def foo(a: int = None) -> ...
and it would imply that the type of 'a' was really Optional[int].
After several years of practice we decided to *remove* this automatic optionalization because it was widely misunderstood and/or confusing for users. For the whole discussion, see https://github.com/python/typing/issues/275. (Also, PEP 484 still mentions it -- "A past version of this PEP allowed ...")
In fact, mypy still defaults to this behavior, and you have to request the new, stricter PEP 484 behavior with `--no-implied-optional`.
Maybe we could satisfy both sides if the notation for Optional[X] was truly short, like ?X or -X. But that has its own issues -- none of the existing unary operators (+X, -X, ~X) really satisfies, and ?X would require a syntax change (and would forever fix the meaning of one of the last ASCII punctuation characters that has no meaning in Python -- $ being the other one).
Finally, I wish the whole term "optional" would go away, because of the endless confusion with optional parameters and optional dict keys -- in these contexts the word is widely used to mean "may or may not be present", without implying that the type may include None.
But I digress...
--Guido
On Wed, May 6, 2020 at 8:47 AM Luciano Ramalho
wrote: Given recent usability improvements in type hints (PEPs 585, 604), I thought I'd raise this minor issue which I find relevant as an instructor.
Given this signature:
def f(a: float, b: Optional[int]) -> float:
The `b` parameter is not optional. The caller must always provide an actual argument as an integer or None. To make `b` optional, we must write:
def f(a: float, b: Optional[int] = None) -> float:
PEP 604 syntax avoids the misleading name `Optional`, which is progress:
def f(a: float, b: int | None = None) -> float:
But now another minor issue is highlighted: the repetition of None. That's unfortunate given that almost all uses of None in parameters are precisely as default values for optional parameters—that the caller doesn't need to provide.
I wonder if the authors of the typing PEPs considered these issues, or if there are ideas to fix them.
I don't have a proposal at this time. I wanted to start the conversation to see if we can find a fix, or at least learn to live with the current status—which is not bad, but also not excellent in terms of readability.
Cheers,
Luciano
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg _______________________________________________ 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) Pronouns: he/him (why is my pronoun here?)
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg