[tyingq]

There are some other warts also, like hard-to-grok errors if you're using typing syntax that's not yet supported in your version of python.

Like:

  somevar: dict[int, int] = {0: 0, 1: 1} 

Produces "TypeError: 'type' object is not subscriptable"

[sco1]

For context, if others aren't familiar: type hinting generics were added to Python 3.9 by PEP 585 (also available in Python 3.7+ with the annotations future import). PEP 484 previously added type hints to Python 3.5 as explicit imports from the stdlib's typing module.

https://peps.python.org/pep-0585/

https://peps.python.org/pep-0484/

[tyingq]

Note that the annotations import from future doesn't help with this one.

https://bugs.python.org/issue45117

[sco1]

Yes, sorry, I forgot about that. It's been a while :)

[miohtama]

Yep, it's a good catch.

Hard-to-grok errors tend to appear for every language and every backwards-compatible change unless the language itself specifies the target version in the source code file itself. The only language I know is doing this is Solidity.

[misnome]

Unless you both a) Don't evaluate them at runtime, and b) import annotations from __future__, in which case it is generally safe to write them like this (and AFAIK all of the usual type-checking tools read them fine).

[tyingq]

Nope. See https://bugs.python.org/issue45117

[misnome]

Yep. This is explicitly what I listed as "as long as you don't (a), evaluating at runtime". This extremely specific and rare case is outside of the scope of "Generally, this works". It means that some, very few definitions still need to be in old style, but the majority of your code is fine.

[tyingq]

I didn't say you couldn't make it work by writing it differently. The point was obscure errors can pop up, which is a drawback to the way they chose to do things. That holds.