Confusing naming of Optional type should be changed
(I apologize in advance if I've posted anything incorrectly before, I believe I might have sent this in python-dev instead but not sure as it's not appearing in the posts for my account). I am aware this is clarified in the Python documentation for the typing module but I and others have thought the naming of Optional is still quite confusing by itself. "Note that this is not the same concept as an optional argument, which is one that has a default. An optional argument with a default does not require the Optional qualifier on its type annotation just because it is optional." - typing.Optional docs Google defines optional as this, "available to be chosen but not obligatory." Pretend we have a function like this: def test_func(param: Optional[str]) -> None: ... The argument param is typed as Optional[str] meaning Union[str, None] or str | None. Optional here if we follow the definition above, basically means it can be str but not required or obligated to be that type. See the problem with the naming? This is a function where param can be None or str, not just it can be str but not obligated. Some interpretations may think optional means left to one's choice as well. The docs even have to clarify the use of Optional with typing because of this confusion. I believe this has been proposed before (not sure) but something like Nullable or Noneable (not sure about naming) would make much more sense in the context of typing. def test_func(param: Noneable[str]) -> None: ... It also would work and still make sense if there is a default value for the argument: def test_func(param: Noneable[str] = None) -> None: ... def test_func(param: Noneable[str] = "hello world") -> None: ...
El jue, 30 jun 2022 a las 10:46, <nverich07@gmail.com> escribió:
(I apologize in advance if I've posted anything incorrectly before, I believe I might have sent this in python-dev instead but not sure as it's not appearing in the posts for my account).
I am aware this is clarified in the Python documentation for the typing module but I and others have thought the naming of Optional is still quite confusing by itself.
"Note that this is not the same concept as an optional argument, which is one that has a default. An optional argument with a default does not require the Optional qualifier on its type annotation just because it is optional." - typing.Optional docs
Google defines optional as this, "available to be chosen but not obligatory."
Pretend we have a function like this: def test_func(param: Optional[str]) -> None: ...
The argument param is typed as Optional[str] meaning Union[str, None] or str | None. Optional here if we follow the definition above, basically means it can be str but not required or obligated to be that type. See the problem with the naming? This is a function where param can be None or str, not just it can be str but not obligated. Some interpretations may think optional means left to one's choice as well. The docs even have to clarify the use of Optional with typing because of this confusion.
I believe this has been proposed before (not sure) but something like Nullable or Noneable (not sure about naming) would make much more sense in the context of typing. def test_func(param: Noneable[str]) -> None: ...
It also would work and still make sense if there is a default value for the argument: def test_func(param: Noneable[str] = None) -> None: ...
def test_func(param: Noneable[str] = "hello world") -> None: ...
This problem has already been solved: in Python 3.10, thanks to PEP 604, you can write `str | None` instead of `Optional[str]`.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GV3ZHU... Code of Conduct: http://python.org/psf/codeofconduct/
I accidentally created another thread in python-dev as I mentioned above, but ideally Optional and Union should both be deprecated and phased out for the new syntax.
nverich07@gmail.com writes:
I accidentally created another thread in python-dev as I mentioned above, but ideally Optional and Union should both be deprecated and phased out for the new syntax.
I think a formal deprecation is a bad idea. An annotation is an object, which has a type. Both the object and the type are going to be visible to users. We don't want there to be warnings about them forever, and Python as a rule does not formally deprecate working code that is expected to continue to work indefinitely. I suspect that it would be difficult to get a stylistic deprecation into PEP 8 (IIRC type annotations are still not allowed in stdlib code so it would be considered out of scope), but you could try lobbying the maintainers of linters. BTW, I disagree with your arguments that Optional and Union are misleading names that can be easily misunderstood, especially in the usual context of formal arguments in function definitions. The suggestion of "Noneable" takes the Pythonic implementation of optional arguments (by defaulting to None) too seriously, at the expense of the syntactic intention: an argument that may be omitted. Among other things, very frequently 'None' is *not* an allowed value in the body of the function, some other value is immediately substituted (and PEP 671 explicitly tries to automate this process for the common case of a mutable default that should be constructed at call time, so that even the idiomatic "if arg is None" statement is left out). "Optional" is the normal term used for such arguments, "union" is the technical term for types composed of being either this or that type. If you need to know any more than that about those types, you're going to have to study up no matter what terms are used. That's just the nature of using natural language words to name things that have a precise definition and implementation in software. Study is required. Steve
The generic collections in typing were deprecated in favor of the generic collections in collections.abc. The objects and the types were exposed to user code, and in the future they will not be
We don't want there to be warnings about them forever
The new wanrings._deprecated https://discuss.python.org/t/introducing-warnings-deprecated/14856 automatically removes features, so deprecations cannot be forgotten anymore On Fri, Jul 1, 2022, 6:19 AM Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
nverich07@gmail.com writes:
I accidentally created another thread in python-dev as I mentioned above, but ideally Optional and Union should both be deprecated and phased out for the new syntax.
I think a formal deprecation is a bad idea. An annotation is an object, which has a type. Both the object and the type are going to be visible to users. We don't want there to be warnings about them forever, and Python as a rule does not formally deprecate working code that is expected to continue to work indefinitely.
I suspect that it would be difficult to get a stylistic deprecation into PEP 8 (IIRC type annotations are still not allowed in stdlib code so it would be considered out of scope), but you could try lobbying the maintainers of linters.
BTW, I disagree with your arguments that Optional and Union are misleading names that can be easily misunderstood, especially in the usual context of formal arguments in function definitions. The suggestion of "Noneable" takes the Pythonic implementation of optional arguments (by defaulting to None) too seriously, at the expense of the syntactic intention: an argument that may be omitted. Among other things, very frequently 'None' is *not* an allowed value in the body of the function, some other value is immediately substituted (and PEP 671 explicitly tries to automate this process for the common case of a mutable default that should be constructed at call time, so that even the idiomatic "if arg is None" statement is left out).
"Optional" is the normal term used for such arguments, "union" is the technical term for types composed of being either this or that type. If you need to know any more than that about those types, you're going to have to study up no matter what terms are used. That's just the nature of using natural language words to name things that have a precise definition and implementation in software. Study is required.
Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LELXP5... Code of Conduct: http://python.org/psf/codeofconduct/
El jue, 30 jun 2022 a las 22:19, Stephen J. Turnbull (< stephenjturnbull@gmail.com>) escribió:
nverich07@gmail.com writes:
I accidentally created another thread in python-dev as I mentioned above, but ideally Optional and Union should both be deprecated and phased out for the new syntax.
I think a formal deprecation is a bad idea. An annotation is an object, which has a type. Both the object and the type are going to be visible to users. We don't want there to be warnings about them forever, and Python as a rule does not formally deprecate working code that is expected to continue to work indefinitely.
I suspect that it would be difficult to get a stylistic deprecation into PEP 8 (IIRC type annotations are still not allowed in stdlib code so it would be considered out of scope), but you could try lobbying the maintainers of linters.
BTW, I disagree with your arguments that Optional and Union are misleading names that can be easily misunderstood, especially in the usual context of formal arguments in function definitions. The suggestion of "Noneable" takes the Pythonic implementation of optional arguments (by defaulting to None) too seriously, at the expense of the syntactic intention: an argument that may be omitted. Among other things, very frequently 'None' is *not* an allowed value in the body of the function, some other value is immediately substituted (and PEP 671 explicitly tries to automate this process for the common case of a mutable default that should be constructed at call time, so that even the idiomatic "if arg is None" statement is left out).
"Optional" is the normal term used for such arguments, "union" is the technical term for types composed of being either this or that type. If you need to know any more than that about those types, you're going to have to study up no matter what terms are used. That's just the nature of using natural language words to name things that have a precise definition and implementation in software. Study is required.
In fact, `typing.Optional` means that something can be None, *not* that it is an optional argument. In other words: def f(x: Optional[str], y: int = 0): ... f(x=None) # allowed f() # not allowed (x is omitted) f(x="", y=None) # not allowed (y cannot be None) That's the opposite of what you describe, so really you're making an argument against the use of the Optional term.
Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LELXP5... Code of Conduct: http://python.org/psf/codeofconduct/
Jelle Zijlstra writes:
In fact, `typing.Optional` means that something can be None, *not* that it is an optional argument.
You're missing my point. Yes, the *implementation* is that the object can be None. But that's far more clearly expressed by Union[T, None] if that's what you *mean*, and it only costs 3 characters. Optional clearly was intended to mean that this type is for use in optional arguments. Having "Optional" at all may have been a bad choice, since (1) it is redundant given you still need to specify "= None" to actually make it optional, and (2) usually shouldn't be used for optional arguments that don't default to None (because in such cases None usually isn't an acceptable argument). I am persuaded of that now: it doesn't express the idea "this type is for use in optional formal arguments". But I am convinced by arguments about the *language* (including type expressions) that are about *what it expresses*, as in the paragraph above (natural language) or your example function f (code example). Arguments about what something *is* in the implementation, or vague statements that things "could" be misinterpreted aren't terribly helpful to me, YMMV. And I think they lead to bad decisions about the language.
BTW, I disagree with your arguments that Optional and Union are misleading names that can be easily misunderstood, especially in the usual context of formal arguments in function definitions.
The comment made by Jelle Zijlstra suggested to me suggested that the new syntax might have been a replacer for Union as well, as that is really what the `|` is. I want to clarify though that I do not think Union is a confusing name as Optional. My main argument in the first place was that Optional was a potentially perplexing name choice.
The suggestion of "Noneable" takes the Pythonic implementation of optional arguments (by defaulting to None) too seriously, at the expense of the syntactic intention: an argument that may be omitted. Among other things, very frequently 'None' is *not* an allowed value in the body of the function
It is kind of an edge case scenario from most common applications in Python. Still, if someone were to allow both None and some other type, I would think using Optional for the naming is more incoherent when it really isn't "optional" if you look at the type alone based on the definition.
While confusion with optional arguments is somewhat unfortunate, the name came from an already established convention. A lot of languages have exactly the same concept, varying between names like Optional, Option, and Maybe. I don't think coming up with a Python-specific name for the same thing is necessarily better. Of course, it's immaterial now that the union syntax is preferred.
Kevin Mills writes:
While confusion with optional arguments is somewhat unfortunate, the name came from an already established convention. A lot of languages have exactly the same concept, varying between names like Optional, Option, and Maybe. I don't think coming up with a Python-specific name for the same thing is necessarily better.
This seems likely to be more or less moot. If you're interested, see Guido's (!!) new PEP 695 (pretty sure that's the number, need to go to meeting that is starting, sorry).
Of course, it's immaterial now that the union syntax is preferred. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4IAHIQ... Code of Conduct: http://python.org/psf/codeofconduct/
participants (5)
-
Jelle Zijlstra -
Kevin Mills -
nverich07＠gmail.com -
Stephen J. Turnbull -
Thomas Grainger