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/LELXP5FPJZWF36NR423ZLVOHGXQTUVKL/
Code of Conduct: http://python.org/psf/codeofconduct/