Type annotations, PEP 649 and PEP 563
(For visibility, posted both to python-dev and Discourse.) Over the last couple of months, ever since delaying PEP 563’s default change in 3.10 <https://mail.python.org/archives/list/python-dev@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/>, the Steering Council has been discussing and deliberating over PEP 563 (Postponed Evaluation of Annotations) <https://www.python.org/dev/peps/pep-0563/>, PEP 649 (Deferred Evaluation Of Annotations Using Descriptors) <https://www.python.org/dev/peps/pep-0649/>, and type annotations in general. We haven’t made a decision yet, but we want to give everyone an update on where we’re at, what we’re thinking and why, see if there’s consensus on any of this, and perhaps restart the discussion around the options. First off, as Barry already mentioned in a different thread <https://mail.python.org/archives/list/python-dev@python.org/message/4TY3MVJQOLKSTMCJRTGAZEOSIIMAWQ45/>, the SC does not want to see type annotations as separate from the Python language. We don’t think it would be good to have the syntax or the semantics diverge, primarily because we don’t think users would see them as separate. Any divergence would be hard to explain in documentation, hard to reason about when reading code, and hard to delineate, to describe what is allowed where. There’s a lot of nuance in this position (it doesn’t necessarily mean that all valid syntax for typing uses has to have sensible semantics for non-typing uses), but we’ll be working on something to clarify that more, later. We also believe that the runtime uses of type annotations, which PEP 563 didn’t really anticipate, are valid uses that Python should support. If function annotations and type annotations had evolved differently, such as being strings from the start, PEP 563 might have been sufficient. It’s clear runtime uses of type annotations serve a real, sensible purpose, and Python benefits from supporting them. By and large, the SC views PEP 649 as a better way forward. If PEP 563 had never come along, it would be a fairly easy decision to accept PEP 649. We are still inclined to accept PEP 649. That would leave the consideration about what to do with PEP 563 and existing from __future__ import annotations directives. As far as we can tell, there are two reasons for code to want to use PEP 563: being able to conveniently refer to names that aren’t available until later in the code (i.e. forward references), and reducing the overhead of type annotations. If PEP 649 satisfies all of the objectives of PEP 563, is there a reason to keep supporting PEP 563’s stringified annotations? Are there any practical, real uses of stringified annotations that would not be served by PEP 649's deferred annotations? If we no longer need to support PEP 563, can we simply make from __future__ import annotations enable PEP 649? We still may want a new future import for PEP 649 as a transitory measure, but we could make PEP 563's future import mean the same thing, without actually stringifying annotations. (The reason to do this would be to reduce the combinatorial growth of the support matrix, and to simplify the implementation of the parser.) This would affect code that expects annotations to always be strings, but such code would have to be poking directly at function objects (the __annotations__ attribute), instead of using the advertised ways of getting at annotations (like typing.get_type_hints()). This question in particular is one in which the SC isn't yet of one mind. Keeping the future import and stringified annotations around is certainly an option, but we’re worried about the cost of the implementation, the support cost, and the confusion for users (specifically, it is a future import that will never become the future). If we do keep them, how long would we keep them around? Should we warn about their use? If we warn about the future import, is the noise and confusion this generates going to be worth it? If we don't warn about them, how will we ever be able to turn them off? One thing we’re thinking of specifically for the future import, and for other deprecations in Python, is to revisit the deprecation and warning policy. We think it’s pretty clear that the policy we have right now doesn’t exactly work. We used to have noisy DeprecationWarnings, which were confusing to end users when they were not in direct control of the code. We now have silent-by-default DeprecationWarnings, where the expectation is that test frameworks surface these warnings. This avoids the problem of end users being confused, but leaves the problem of the code’s dependencies triggering the warning, and thus still warns users (developers) not necessarily in a position to fix the problem, which in turn leads to them silencing the warning and moving on. We need a better way to reach the users in a position to update the code. One idea is to rely on linters and IDEs to provide this signal, possibly with a clear upgrade path for the code (e.g. a 2to3-like fixer for a specific deprecation). Support for deprecations happened to be brought up on the typing-sig mailing list not too long ago <https://mail.python.org/archives/list/typing-sig@python.org/thread/E24WTMQUTGKPFKEXVCGGEFFMG7LDF3WT/#5DXUZMF6Q5YYBW2N6ZPTU77GRFH3B4L3>, as an addition to the pytype type checker and hopefully others (full disclosure, Yilei is a team-mate of Thomas’s at Google). This sounds like a reasonably user-friendly approach, but it would require buy-in from linter/IDE developers, or an officially supported “Python linter” project that we control. There’s also the question of support timelines: most tooling supports a wider range of Python versions than just the two years that we use in our deprecation policy. Perhaps we need to revisit the policy, and consider deprecation timelines based on how many Python versions library developers usually want to support. The SC continues to discuss the following open questions, and we welcome your input on them: 1. Is it indeed safe to assume PEP 649 satisfies all reasonable uses of PEP 563? Are there cases of type annotations for static checking or runtime use that PEP 563 enables, which would break with PEP 649? 2. Is it safe to assume very little code would be poking directly at __annotations__ attributes of function objects; effectively, to declare them implementation details and let them not be strings even in code that currently has the annotations future import? 3. Is the performance of PEP 649 and PEP 563 similar enough that we can outright discount it as a concern? Does anyone actually care about the overhead of type annotations anymore? Are there other options to alleviate this potential issue (like a process-wide switch to turn off annotations)? 4. If we do not need to keep PEP 563 support, which would be a lot easier on code maintenance and our support matrix, do we need to warn about the semantics change? Can we silently accept (and ignore) the future import once PEP 649 is in effect? 5. If we do need a warning, how loud, and how long should it be around? At the end of the deprecation period, should the future import be an error, or simply be ignored? 6. Are there other options we haven’t thought of for dealing with deprecations like this one? Like I said, the SC isn’t done deliberating on any of this. The only decisions we’ve made so far is that we don’t see the typing language as separate from Python (and thus won’t be blanket delegating typing PEPs to a separate authority), and we don’t see type annotations as purely for static analysis use. For the whole SC, Thomas. -- Thomas Wouters <thomas@python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!
Am 20.10.21 um 15:18 schrieb Thomas Wouters:
By and large, the SC views PEP 649 as a better way forward. If PEP 563 had never come along, it would be a fairly easy decision to accept PEP 649. We are still inclined to accept PEP 649. That would leave the consideration about what to do with PEP 563 and existing from __future__ import annotationsdirectives. As far as we can tell, there are two reasons for code to want to use PEP 563: being able to conveniently refer to names that aren’t available until later in the code (i.e. forward references), and reducing the overhead of type annotations. If PEP 649 satisfies allof the objectives of PEP 563, is there a reason to keep supporting PEP 563’s stringified annotations? Are there any practical, real uses of stringified annotations that would not be served by PEP 649's deferred annotations?
These are my reasons for using from __future__ import annotations: * Forward references and cyclic imports (with if TYPE_CHECKING: from foo import Bar) while avoiding quotes. * Using typing features from future Python versions. This becomes less important the more typing stabilizes. - Sebastian
One use case which seems significant to me but I don’t think has been explicitly mentioned is annotations using a package with stubs where the stubbed typing API is slightly different than the runtime API. For example sometimes additional tape aliases are defined for convenience in stubs without a corresponding runtime name, or a class is generic in the stubs but has not yet been made to inherit typing.Generic (or just made a subscriptable class), in runtime. These situations are described in the mypy docs: https://mypy.readthedocs.io/en/latest/runtime_troubles.html#using-classes-th.... These are easy to write without problems using PEP 563, but I am not sure how they would work with PEP 649. I believe this pattern may be useful in complex existing libraries when typing is added, as it may be difficult to convert an existing class to generic. For example with numpy, the core ndarray class was made generic in stubs to support indicating the shape and data type. You could only write eg ndarray[Any, np.int64] using PEP 563. A while later a workaround was added by defining __class_getitem__.
I'm sorry, I sent my last mail too early. Here are the rest of my thoughts. Am 20.10.21 um 15:18 schrieb Thomas Wouters:
Keeping the future import and stringified annotations around is certainly an option, but we’re worried about the cost of the implementation, the support cost, and the confusion for users (specifically, it is a future import that will never become the future). If we do keep them, how long would we keep them around? Should we warn about their use? If we warn about the future import, is the noise and confusion this generates going to be worth it? If we don't warn about them, how will we ever be able to turn them off?
Personally, I think that stringified annotations should be deprecated and eventually be removed. This opens the design space to use quotes for different purposes, for example getting rid of the cumbersome need to use Literal for literals.
One thing we’re thinking of specifically for the future import, and for other deprecations in Python, is to revisit the deprecation and warning policy. We think it’s pretty clear that the policy we have right now doesn’t exactly work. We used to have noisy DeprecationWarnings, which were confusing to end users when they were not in direct control of the code. We now have silent-by-default DeprecationWarnings, where the expectation is that test frameworks surface these warnings. This avoids the problem of end users being confused, but leaves the problem of the code’s dependencies triggering the warning, and thus still warns users (developers) not necessarily in a position to fix the problem, which in turn leads to them silencing the warning and moving on. We need a better way to reach the users in a position to update the code.
+1
1.
If we do need a warning, how loud, and how long should it be around? At the end of the deprecation period, should the future import be an error, or simply be ignored?
The future import should remain active and should continue to work as it does now (without warning) as long as there are Python versions supported that have not implemented PEP 649, i.e. Python 3.10. Otherwise, existing code that provides supports for these older versions (especially libraries) have to regress their typing support. For example, a library supporting 3.8+ could have the following code: from __future__ import annotations def foo(x: int | str): pass If newer versions stop supporting the future import or warn about it, the library would have to go back to using typing.Union here. Other constructs would even be impossible to use. After that, I would recommend to start the normal "warn"/"remove" cycle for the future import. Don't keep it around if it's doing nothing. - Sebastian
Thanks to the SC for such a thoughtful note. I really like where this is going. One thought. On Wed, Oct 20, 2021 at 6:21 AM Thomas Wouters <thomas@python.org> wrote:
1.
Is the performance of PEP 649 and PEP 563 similar enough that we can outright discount it as a concern? Does anyone actually care about the overhead of type annotations anymore? Are there other options to alleviate this potential issue (like a process-wide switch to turn off annotations)?
Annotations are used at runtime by at least one std lib module: dataclasses, and who knows how many third party libs. So that may not be practical. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Thu, Oct 21, 2021 at 6:38 AM Christopher Barker <pythonchb@gmail.com> wrote:
Thanks to the SC for such a thoughtful note. I really like where this is going.
One thought.
On Wed, Oct 20, 2021 at 6:21 AM Thomas Wouters <thomas@python.org> wrote:
Is the performance of PEP 649 and PEP 563 similar enough that we can outright discount it as a concern? Does anyone actually care about the overhead of type annotations anymore? Are there other options to alleviate this potential issue (like a process-wide switch to turn off annotations)?
Annotations are used at runtime by at least one std lib module: dataclasses, and who knows how many third party libs. So that may not be practical.
This is similar to docstring. Some tools using docstring (e.g. docopt) prevent using -OO option. Although some library (e.g. SQLAlchemy) has huge docstring, we can not use -OO if a time set of module depends on docstring or assertion. So I think we need some mechanizm to disable optimization like dropping assertions, docstrings, and annotations per module. -- Inada Naoki <songofacandy@gmail.com>
On 20 Oct 2021, at 15:18, Thomas Wouters <thomas@python.org> wrote:
(For visibility, posted both to python-dev and Discourse.)
Since this got split into Discourse and python-dev, I wrote my take on the issue on the blog so that I could post it in both spaces with proper formatting and everything: https://lukasz.langa.pl/61df599c-d9d8-4938-868b-36b67fdb4448/ <https://lukasz.langa.pl/61df599c-d9d8-4938-868b-36b67fdb4448/> - Ł
Hello!
This would affect code that expects annotations to always be strings, but such code would have to be poking directly at function objects (the __annotations__ attribute), instead of using the advertised ways of getting at annotations (like typing.get_type_hints()).
I would speculate that this is somewhat common to find. What I don't think is common enough to consider is code that directly relies on the annotations being strings. The majority of code will be trying to retrieve the actual underlying types. The potential one script out there in the solarsystem that relies on this can just wrap the result in str(...) to ensure it's in-fact a string.
Keeping the future import and stringified annotations around is certainly an option, but we’re worried about the cost of the implementation, the support cost, and the confusion for users (specifically, it is a future import that will never become the future). If we do keep them, how long would we keep them around? Should we warn about their use? If we warn about the future import, is the noise and confusion this generates going to be worth it? If we don't warn about them, how will we ever be able to turn them off?
I quite particularly like what Łukasz Langa brought up under the header "A better possible future" in their blog post here: https://lukasz.langa.pl/61df599c-d9d8-4938-868b-36b67fdb4448/ (which has been listed in another reply here). I will quote part of the paragraph below (read 2021-10-22; last updated 2021-10-21):
if the library author is fine with DeprecationWarnings, they could keep using `from __future__ import annotations` until Python 3.13 is released (October 2023). [...]. So I would advise marking the old future-import as “pending deprecation” until 3.13 and only fully deprecate it then for two releases, so it would be removed in Python 3.14 (𝛑) in October 2025 when Python 3.9 goes EOL.
This seems like the sense of direction in terms of a compromise that I would like to see.
One idea is to rely on linters and IDEs to provide this signal, possibly with a clear upgrade path for the code (e.g. a 2to3-like fixer for a specific deprecation). [...] This sounds like a reasonably user-friendly approach, but it would require buy-in from linter/IDE developers, or an officially supported “Python linter” project that we control.
I think this is a nice step in the right direction as you mention test frameworks have had this role so I don't see the issue in also extending this to static analysis tools (static type checkers, linters and IDEs). Couldn't the "Python linter" simply be the current behaviour when you opt-into it?
Is it safe to assume very little code would be poking directly at __annotations__ attributes of function objects; effectively, to declare them implementation details and let them not be strings even in code that currently has the annotations future import?
I believe so, see my comments further up in this reply. It was never safe to assume that all annotations were strings (in my opinion on writing good code) and so yes I believe this would be a non-breaking change and could be considered an implementation detail.
Is the performance of PEP 649 and PEP 563 similar enough that we can outright discount it as a concern? Does anyone actually care about the overhead of type annotations anymore? Are there other options to alleviate this potential issue (like a process-wide switch to turn off annotations)?
In my opinion this shouldn't warrant any concern as these costs are only on startup of Python. The difference is not enough for me to care at least.
If we do not need to keep PEP 563 support, which would be a lot easier on code maintenance and our support matrix, do we need to warn about the semantics change? Can we silently accept (and ignore) the future import once PEP 649 is in effect?
In terms of semver I don't think this causes a breaking change that warrants a major bump. That said this change should be made aware to the broader Python community so that it reaches those who are affected by this change. Have a good weekend
On Sat, Oct 23, 2021 at 5:55 AM Bluenix <bluenixdev@gmail.com> wrote:
Is the performance of PEP 649 and PEP 563 similar enough that we can outright discount it as a concern? Does anyone actually care about the overhead of type annotations anymore? Are there other options to alleviate this potential issue (like a process-wide switch to turn off annotations)?
In my opinion this shouldn't warrant any concern as these costs are only on startup of Python. The difference is not enough for me to care at least.
Costs are not only on startup time. Memory consumption is cost on process lifetime. And longer GC time is every time when full-GC is happened. So performance is problem for both of short lifecycle applications like CLI tools and long lifecycle applications like Web app. Regards, -- Inada Naoki <songofacandy@gmail.com>
Hmm, I thought I responded to this on Gmail but it hasn't appeared here on the archive so I'll send it again.. Is it known how much more/less the annotations impact performance compared to function defaults? -- Blue
On Sun, Oct 24, 2021 at 6:03 AM Bluenix <bluenixdev@gmail.com> wrote:
Hmm, I thought I responded to this on Gmail but it hasn't appeared here on the archive so I'll send it again..
Is it known how much more/less the annotations impact performance compared to function defaults?
Basically, PEP 563 overhead is the same as function defaults. * Function annotations are one constant tuple per function. * Functions having the same signature share the same annotation tuple. * No GC overhead because it is constant (not tracked by GC). On the other hand, it is difficult to predicate PEP 649 overhead. When namespace is not kept: * Annotation is just a constant tuple too. * No GC overhead too. * The constant tuple will be slightly bigger than PEP 563. (It can be the same as PEP 563 when all annotations are constant.) * Although they are constant tuples, they may have their own names and firstlineno. So it is difficult to share whole annotation data between functions having the same signature. (*) (*) I proposed to drop firstlineno and names to share more annotations. See https://github.com/larryhastings/co_annotations/pull/9 When namespace is kept: * Annotations will be GC tracked objects. * They will be heavier than the "namespace is not kept", for both of startup time and memory consumption. * They have some GC overhead. To answer "how much more", we need a target application. But I don't have a good target application for now. Additionally, even if we have a good target application, it is still difficult to estimate real future impact. For example, SQLAlchemy has very heavy docstrings so the `-OO` option has a big impact. But SQLAlchemy doesn't use function annotations yet. So stock/PEP 563/PEP 649 have the same (zero) cost. Yay! But if SQLAlchemy starts using annotations, *all applications* using SQLAlchemy will be impacted in the future. Regards, -- Inada Naoki <songofacandy@gmail.com>
* Functions having the same signature share the same annotation tuple.
Is this true with code that have a mutable default?
def a(arg = []): ... arg.append('a') ... return arg ... def b(arg = []): ... arg.append('b') ... return arg ... a() ['a'] a() ['a', 'a'] a() ['a', 'a', 'a'] b() ['b'] b() ['b', 'b'] b() ['b', 'b', 'b']
On 10/26/21 5:22 PM, Bluenix wrote:
* Functions having the same signature share the same annotation tuple. Is this true with code that have a mutable default? [... examples deleted...]
You're confusing two disjoint concepts. First of all, all your examples experiment with default values which are unrelated to their annotations. None of your examples use or examine annotations. Second, Inada-san was referring to the tuple of strings used to initialize the annotations for a function when PEP 583 (stringized annotations) is active. This is a clever implementation tweak that first shipped with Python 3.10, which makes stringized annotations very efficient. Since all the names and annotations are strings, rather than creating the dictionary at function binding time, they're stored in a tuple, and the dictionary is created on demand. This tuple is a constant object, and marshalling a module automatically collapses duplicate constants into the same constant. So identical PEP 583 annotation tuples are collapsed into the same tuple. Very nice! //arry/
participants (8)
-
asafspades＠gmail.com -
Bluenix -
Christopher Barker -
Inada Naoki -
Larry Hastings -
Sebastian Rittau -
Thomas Wouters -
Łukasz Langa