--py312-plus: `type ...` aliases

[asottile]

-IntOrStr: TypeAlias = int | str
+type IntOrStr = int | str

from PEP 695

[asottile]

really annoying part of the PEP that makes this not easily auto-rewritable:

Type alias expressions are not allowed to use traditional type variables (i.e. those allocated with an explicit TypeVar constructor call). Type checkers should generate an error in this case.

T = TypeVar("T")
type MyList = list[T] # Type checker error: traditional type variable usage

but maybe we just do it anyway and the user can deal? shrugs

[asottile]

it's also unclear to me when quoted forward references would ever be needed inside them. my reading of the PEP seems to indicate they are allowed but completely unnecessary... unclear.

if they're unnecessary -- the PEP 563 rewriter should apply to these as well

[asottile]

also perhaps even to the TypeVar bounds -- I've currently made them only rewrite if __future__.annotations is present -- but my reading of the PEP seems to mirror my thoughts in #836 (comment) as well so maybe this can be done unconditionally

[asottile]

wellp, this seems to be poorly specced because it breaks code that uses the type alias at runtime

for instance:

>>> from typing import TypeAlias
>>> a: TypeAlias = int
>>> isinstance(1, a)

but after rewrite it would not work at all:

>>> type a = int
>>> isinstance(1, a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: isinstance() arg 2 must be a type, a tuple of types, or a union

:(

[aiven-anton]

Hi there, hope you are all good 👋

What was the resolution of this one? I see it's closed as completed and #914 that was mentioning the other features of the same PEP was closed as duplicate, and I don't see any PR referencing this issue or any mention of the --py312-plus feature flag in the README. Should the last comment be interpreted as there is no (reasonable) safe way to implement rewrites for the features of PEP 695?

[asottile]

read the comment directly above yours?

[aiven-anton]

@asottile I did, and I read it as observing a challenge with the CPython implementation and I just wanted to verify whether this was ultimately a complete blocker for any PEP 695 rewrites, including those not involving type aliases at all (why I mention the duplicate). Do you remember whether that was the case?

I see how rewriting generics could be similarly challenging wrt to replacing/"inlining" type variables, but I didn't see anything explicitly mentioning it here.

[asottile]

this issue clearly isn't about that as you can see from the title and description -- and with a little bit of thinking I'm sure you can figure out why the rest of the PEP isn't rewritable