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 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

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

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

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.