5 ms·
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: d
by tyingq 3y ago
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"
- miohtama 3y agoYep, 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.
- sco1 3y agoFor 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-0585/ https://peps.python.org/pep-0484/ https://peps.python.org/pep-0484/
- misnome 3y agoUnless 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 3y agoNope. See https://bugs.python.org/issue45117 https://bugs.python.org/issue45117
- misnome 3y agoYep. 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 3y agoI 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.