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.

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.

+1--
--Guido (mobile)

New changeset e1abffc by Gregory Beauregard in branch 'main':
bpo-46491: Allow Annotated on outside of Final/ClassVar (GH-30864)
e1abffc

New changeset 41e0aea by Miss Islington (bot) in branch '3.10':
bpo-46491: Allow Annotated on outside of Final/ClassVar (GH-30864)
41e0aea

New changeset b0b8388 by Miss Islington (bot) in branch '3.9':
bpo-46491: Allow Annotated on outside of Final/ClassVar (GH-30864)
b0b8388

Thanks Gregory for fixing this!

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

But it *is* a bugfix.

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

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.

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

Yeah, there are no perfect solutions. Please let it go.