TypeForm/type compatibility

[hmc-cs-mdrissi]

I was unsure on discussion vs issue, but leaned discussion as this still open here with last comment on it about month back.

My codebase often calls functions that are intended for TypeForm most commonly with Unions for non-basic types. I tried testing pyright with enableExperimentalFeatures on. One common code pattern that triggered errors,

def g[T](x: TypeForm[T]) -> T:
  ...

def f(x: type): # or maybe it's more specific like x: type[Foo] for some previously defined protocol/class Foo.
  g(x) # type is not compatible with TypeForm

or maybe,

def g[T](x: TypeForm[T]) -> T:
  ...

def f(x: type[T]) -> T:
  g(x) # type is not compatible with TypeForm

Realistic cases having more stuff happening in f besides just g, but that's core of it.

Are you open to relaxing this/making them compatible? Or waiting for more discussion in forum/mypy implementation to compare behavior on.

One thing I also noticed is some of strictness on type vs typeform is different with 3.9 vs 3.10. This is likely typeshed related, but recently upgrading to 3.10 it's increased my want to enable TypeForm. I'm just unsure if I want to add several dozen type ignores for code similar to the example.

[erictraut]

I feel like we're at somewhat of an impasse on the other thread.

There are at least three different viewpoints voiced in that thread.

1. There should be no special-cased subtypes of TypeForm[T]. Only valid type expressions or an expression that evaluates to TypeForm[T] should be assignable to TypeForm[T].
2. We admit type[T] as a special-case subtype of TypeForm[T].
3. We allow any type that could potentially represent a valid type form to be treated as a subtype of TypeForm[T] even if a static type checker cannot enforce the validity (e.g. the expression Literal[some_variable] or f"${type_name}[int]") or if the type involves an undocumented class or a class that has no definition in typeshed.

Carl has been an advocate of option 3. I'm pretty opposed to this, as it's unsound in some cases (like the examples I gave above), would be nearly impossible to spec because of the diversity of undocumented types used to encode type forms at runtime, and would be an ongoing maintenance burden as this list expands from one Python release to the next. I don't know how strongly Carl feels about his position.

I could maybe be convinced to support option 2, but I would first like to hear a principled justification for special-casing only type[T], and no one has yet provided such an argument. For that reason, I'm still advocating for option 1. David (who is the original author of the PEP) seems to be willing to adopt option 2 as a compromise, but I'm not there yet.

If you want to advance the discussion, perhaps you can come up with some principle or rule that justifies why we would special-case type[T] as a subtype and not special-case any others. Or perhaps you can come up with a compromise that I haven't yet thought of.

Back to your particular code sample above... If your code needs to support both TypeForm[T] and type[T], you have the option of using TypeForm[T] | type[T]. Do you see any problems with this, other than it being perhaps more verbose than you'd prefer?

In any case, I wouldn't recommend using TypeForm in your production code at this time. I'm glad you're trying it out and providing feedback, but this PEP could still change or be abandoned if we are unable to reach consensus.

[erictraut]

If I understand your argument correctly (it's stated in a rather contorted manner), then I think that's a reasonable (and objective) principle that we could use. Maybe we can find a crisper and clearer way to state it.

Other potential constraints that we could add to your rule:

1. It applies only to classes that are officially documented and included in typeshed stubs. For example, _LiteralGenericAlias does not meet this requirement because it's not documented, is named such that it's private, and does not appear in typeshed.
2. It applies only to types that can be used to solve T when the type is assigned to TypeForm[T]. This means it does not apply to a value of type TypeAliasType or GenericAlias because T would go unsolved in these cases (or would need to be solved as Any).

If we combine your rule with my two, can you think of any other examples other than type[T] that meet these requirements?

[hmc-cs-mdrissi]

Sure type[int] | type[T] would is another example that satisfies both my rule and your extra two rules. Annotated[type[T], "..."] would also fit in same way Annotated[A, "..."] should be compatible with same values as A. Another example would something like type[Foo[T]] (any generic not just Foo works here) where is some generic protocol. Or maybe type[Callable[..., T]]. Or other metaclasses like,

class MyMeta(type[T]):
  ...

class Foo(metaclass=MyMeta[int]):
    ...

def f[T](x: MyMeta[T]) -> T:
    ...

f(Foo)

MyMeta[T] satisfies the stated rules. I don't actually have any use case for custom metaclasses like this, but it follows the same principles.

edit: If you mean example that's not also subtype of type[T], I'm unsure of one and need to think more.

edit 2: Literal["int"]. x: Literal["int"] is close. For functions,

def f1(x: TypeForm[T]):
  ...

vs

def f2(x: TypeForm[T] | Literal["int"]):
  ...

What's a sound program that uses f2 that does not work with f1? Literal["int"] only allows "int" as a value which is valid TypeForm. This example feels silly, but gets close rule wise. I think it fails with your rule 2 of solves T though.

[erictraut]

I think you're conflating value expressions with the type encoded by a type form object that results when evaluating that value expression at runtime.

Let's look at a few examples.

x = Annotated[A, "..."]
reveal_type(x)

What type is x? At runtime, it's an instance of typing._AnnotatedAlias, which is a private class. What do static type checkers reveal in this case? Pyright reveals Annotated, and mypy reveals def () -> A. There's no consistency because this isn't specified, and the classes are not even documented. If we apply my rules above, that means you wouldn't be able to assign x to TypeForm[Any].

Here's another example that doesn't meet these requirements.

x = Literal["a"]
reveal_type(x)

At runtime, x is an instance of typing._LiteralGenericAlias, which is a private type. Pyright reveals type[Literal], and mypy reveals typing._SpecialForm. This means you wouldn't be able to assign x to TypeForm[Any] because it doesn't meet either of my rules above.

By contrast:

x = A
reveal_type(x)

The runtime type of x is <class A>, and pyright and mypy both agree that the revealed type is type[A]. This is a documented type, and it is assignable to TypeForm[T] in a way that allows us to solve for T. This meets all three constraints we listed above.

[hmc-cs-mdrissi]

Yes I think I was confused and rule I had in mind was bit different. But I'm happy with your examples and the results they lead to.

I'm not confident on how to make the 1st rule clearer. I can think more on it later this week.

[Tinche]

Hello, I'm the author of cattrs (which has been mentioned in this discussion) and I've been waiting for TypeForm for a long time ;)

I'm happy to change my type hints to TypeForm[C] | type[C] if that's what we decide to go with. It feels like a small wart in the type system that I need to know to do though though, and anyone wrapping cattrs functionality will probably need to know to do it too. I think it's going to require extra energy to explain to folks why exactly this is necessary, and typing in Python is already met with skepticism from certain parts of our community because of perceived complexity (not to get into this now). But like I said, I don't feel very strongly about it.