This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: typing: allow Annotated in outermost scope
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.11, Python 3.10, Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Anthony Sottile, GBeauregard, JelleZijlstra, gvanrossum, kj, miss-islington
Priority: normal Keywords: patch

Created on 2022-01-23 19:03 by GBeauregard, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 30864 merged GBeauregard, 2022-01-24 23:53
PR 30873 merged miss-islington, 2022-01-25 06:37
PR 30874 merged miss-islington, 2022-01-25 06:37
Messages (13)
msg411404 - (view) Author: Gregory Beauregard (GBeauregard) * Date: 2022-01-23 19:03
Currently, `typing.Annotated` (PEP 593) cannot be used at runtime with `typing.Final` and `typing.ClassVar` with `Annotated` on the outside:

```
from typing import Annotated, Final
# TypeError: typing.Final[int] is not valid as type argument
var: Annotated[Final[int], "foo"] = 4
```

The only tenuously related mention of this I can find in a PEP is in PEP 593 (Annotated) which states "The first argument to Annotated must be a valid type".

I believe the runtime behavior should be changed to allow any ordering for `Annotated` with `ClassVar` and `Final`. This was discussed in the typing-sig PEP 655 thread (TypedDict `Required` and `NotRequired`) where the current plan is to allow `Required`/`NotRequired` in any nesting order with `Annotated` while suggesting the `ClassVar`/`Final` ordering restriction be lifted: https://mail.python.org/archives/list/typing-sig@python.org/message/22CJ5TJGIJ563D6ZKB7R3VUZXTZQND5X/

The argument for doing so is on the mailing list: https://mail.python.org/archives/list/typing-sig@python.org/message/MPMOIBX3XFXCD4ZNDC6AV4CLSI5LN544/

To summarize: adopting an overly strict view of what constitutes a valid type for `Annotated` creates difficulties for people who use runtime introspection of `Annotated` annotations by requiring them to parse additional typing or field annotations (https://bugs.python.org/msg411067). This needlessly exacerbates tension between typing and non-typing uses of annotation space. In order to be a good citizen to other annotation users, the `Annotated` runtime ordering restriction should be lifted.
msg411405 - (view) Author: Jelle Zijlstra (JelleZijlstra) * (Python committer) Date: 2022-01-23 19:07
I support making this change. It looks like the simplest implementation is simply to remove the mention of ClassVar and Final in typing._type_check.
msg411418 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-01-23 20:55
+1--
--Guido (mobile)
msg411557 - (view) Author: miss-islington (miss-islington) Date: 2022-01-25 06:37
New changeset e1abffca45b60729c460e3e2ad50c8c1946cfd4e by Gregory Beauregard in branch 'main':
bpo-46491: Allow Annotated on outside of Final/ClassVar (GH-30864)
https://github.com/python/cpython/commit/e1abffca45b60729c460e3e2ad50c8c1946cfd4e
msg411598 - (view) Author: miss-islington (miss-islington) Date: 2022-01-25 14:38
New changeset 41e0aead3defa6d0486514e313b6975fbf375998 by Miss Islington (bot) in branch '3.10':
bpo-46491: Allow Annotated on outside of Final/ClassVar (GH-30864)
https://github.com/python/cpython/commit/41e0aead3defa6d0486514e313b6975fbf375998
msg411599 - (view) Author: miss-islington (miss-islington) Date: 2022-01-25 14:39
New changeset b0b8388a1c29dc9203dd1a9e8b1420a6a5e88c97 by Miss Islington (bot) in branch '3.9':
bpo-46491: Allow Annotated on outside of Final/ClassVar (GH-30864)
https://github.com/python/cpython/commit/b0b8388a1c29dc9203dd1a9e8b1420a6a5e88c97
msg411600 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2022-01-25 14:40
Thanks Gregory for fixing this!
msg411686 - (view) Author: Anthony Sottile (Anthony Sottile) * Date: 2022-01-25 23:27
should this behaviour change be backported?  it potentially creates an annoying edgecase where code seemingly works unless you use an older patch version

since this isn't a bugfix I wouldn't expect this to land in 3.9 and 3.10
msg411688 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-01-25 23:36
But it *is* a bugfix.
msg411690 - (view) Author: Anthony Sottile (Anthony Sottile) * Date: 2022-01-25 23:59
to me this is the same as the Union[Pattern] / Union[Match] "fixes" that landed in 3.5.3 -- and the pain caused by using that and having CI pass (because of modern 3.5.x) but having spurious bug reports from users stuck on 3.5.2

or in 3.6.1 when NamedTuple was "fixed" to allow methods, again having CI pass with modern pythons but having frustrated users running 3.6.0

I forsee the same class of problems here with Annotated where it works great in 3.10.3 and 3.9.11 but anyone stuck on 3.10.2 or 3.9.10 or older will be broken
msg411691 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-01-26 00:13
Well that's *always* a problem right? If you take that to the extreme we wouldn't need bugfix releases. :-)

Apart from some examples in the 3.5-3.6 timeframe, what makes you think that *this* fix *specifically* is going to make more people unhappy than it makes happy?

When people complain that they wrote Annotated[ClassVar[int], ...] and are disappointed that it doesn't work in a certain old version, you can just tell them to use ClassVar[Annotated[int, ...]] which is in no way invalid or inferior and works in all versions that support Annotated.
msg411692 - (view) Author: Anthony Sottile (Anthony Sottile) * Date: 2022-01-26 00:21
3.7.2 has another example where OrderedDict was added to typing

I don't have any personal investment in this particular change but I've had quite a few unhappy consumers of libraries due to instability in typing apis between patch versions in the past (heh and they're especially frustrated because they don't care about type checking and just want functional software)

it's also difficult and/or not cost effective to add every patch version to a CI matrix to catch these sorts of problems
msg411693 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-01-26 00:26
Yeah, there are no perfect solutions. Please let it go.
History
Date User Action Args
2022-04-11 14:59:55adminsetgithub: 90649
2022-01-26 00:26:54gvanrossumsetmessages: + msg411693
2022-01-26 00:21:58Anthony Sottilesetmessages: + msg411692
2022-01-26 00:13:06gvanrossumsetmessages: + msg411691
2022-01-25 23:59:51Anthony Sottilesetmessages: + msg411690
2022-01-25 23:36:25gvanrossumsetmessages: + msg411688
2022-01-25 23:27:27Anthony Sottilesetnosy: + Anthony Sottile
messages: + msg411686
2022-01-25 14:40:07kjsetstatus: open -> closed
resolution: fixed
messages: + msg411600

stage: patch review -> resolved
2022-01-25 14:39:15miss-islingtonsetmessages: + msg411599
2022-01-25 14:38:54miss-islingtonsetmessages: + msg411598
2022-01-25 06:37:38miss-islingtonsetmessages: + msg411557
2022-01-25 06:37:35miss-islingtonsetpull_requests: + pull_request29054
2022-01-25 06:37:29miss-islingtonsetnosy: + miss-islington
pull_requests: + pull_request29053
2022-01-24 23:53:43GBeauregardsetkeywords: + patch
stage: patch review
pull_requests: + pull_request29045
2022-01-23 20:55:52gvanrossumsetmessages: + msg411418
2022-01-23 19:07:41JelleZijlstrasetnosy: + gvanrossum, JelleZijlstra, kj
messages: + msg411405
components: + Library (Lib)
2022-01-23 19:03:20GBeauregardcreate