Treat alternative syntax for unions (and other "new-semantics-old-syntax" typing features) in explicit `TypeAlias`es inside `if TYPE_CHECKING` blocks as stringized annotations.
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.8k
- Forks
- 302
- Avg merge
- 23h
- Merged PRs (30d)
- 8
Description
The Problem
At runtime, TYPE_CHECKING is always False, only type checkers assume it is True. Therefore, if TYPE_CHECKING blocks are only parsed, but never evaluated by the Python interpreter. Since A = int | str is a valid syntax for all still-supported Python versions at the moment (all versions ever since typing was introduced, actually), it would make sense if type checkers were allowed to accept usage of "new-semantics-old-syntax" features (like the alternative union syntax) in explicitly-annotated TypeAliases inside of if TYPE_CHECKING blocks as long as the Python version specified [project.requires-python] (or it's equivalent in tools) can successfully parse that syntax. This is essentially the same as treating explicitly-annotated TypeAliases as stringized annotations by-default.
Examples
# Run on 3.9
from typing import TYPE_CHECKING
if TYPE_CHECKING:
A = int | str # Alternative syntax for unions requires Python 3.10 or newer # pyright
# Invalid type alias: expression is not a valid type # mypy
# Unsupported left operand type for | ("type[int]") # mypy
# With proposal
from typing import TYPE_CHECKING
from typing_extensions import TypeAlias
if TYPE_CHECKING:
A: TypeAlias = int | str # Treated as a stringized annotation because `: TypeAlias`
# is explicit, therefore valid.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked pyright-play and mypy-play examples, focusing on Python 3.9, TYPE_CHECKING, and explicitly annotated TypeAliases. No repository files or tests are identified; done would require a settled specification for how these cases should be interpreted and corresponding agreement or implementation work in the relevant type-checking tools.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100