El jue, 30 jun 2022 a las 22:19, Stephen J. Turnbull (< stephenjturnb...@gmail.com>) escribió:
> nveric...@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-le...@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/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/7CGTM6CNP3QHB6UXZMTP3KKZ5D47YT42/ Code of Conduct: http://python.org/psf/codeofconduct/
