GeezerVison

I like the comments you're adding to link to the CPython PRs, but I'd leave the sys.version_info conditions as they are unless we know of an actual problem that needs to be fixed here. This kind of change has caused significant breakage for users in the past in ways that were hard for us to anticipate ahead of time; it doesn't seem worth it to me to change anything here.

Sorry, but I’m not quite sure what kind of breakages could occur in this case, especially for sys.version_info checks before importing attributes. I’m having trouble imagining how this change might cause issues. Could you elaborate or give an example?

Sure, sorry for being vague! In #145, for example, I made it so that typing_extensions.Literal was no longer the same object as typing.Literal on Python <=3.9.0 (previously it had been the same object as typing.Literal on all Python versions >=3.8). Pydantic had internal code that incorrectly assumed that typing_extensions.Literal would always be the same object as typing.Literal on Python 3.8+, so this broke pydantic, causing a lot of disruption across the ecosystem and meaning we had to do a hotfix release of typing_extensions:

• Cannot use Literal when I use typing-extension==4.6.0 pydantic/pydantic#5821
• TypeError: issubclass() arg 1 must be a class with version 4.6.0 with pydantic #179
• TypeError after upgrading version to 4.6.0 #182
• Release 4.6.0 breaks Pydantic 1.9.2 #183

I don't think it's very likely that the specific changes you proposed here would cause that kind of breakage! But over the years of maintaining typing_extensions, I've come to realise that you really can't predict what kind of assumptions people are making about things like this -- I had no idea that change would break pydantic! So it's better not to make changes like this unless they're actually fixing something :-)