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/