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.

[carljm]

Thanks, @hmc-cs-mdrissi ! What I'm gathering is that one reason we may see a lot of TypeForm[C] | type[C] is just backward compatibility, since currently many libraries are using type[C] for this scenario. This doesn't bother me much; it's OK for backwards-compatibility to require some non-ideal workarounds.

Regarding the example of C vs C().__class__, what I'm trying to understand is how much (and why) it would matter to such a library to accept something like C().__class__. Barring backwards-compatibility with existing APIs using type[C], would it be important enough for a runtime typing library to accept invalid-type-expression spellings of a type that it would frequently motivate them to write TypeForm[C] | type[C] instead of just TypeForm[C]? If so, what real use cases (not useless invented ones like C().__class__) would motivate that? (I understand that "the function can handle it at runtime", but that alone isn't sufficient reason for the more complex annotation, unless there's some caller demand for it.)

[carljm]

I think a good next step is to update the PEP to include (in the rejected-alternatives section, as mentioned above) a clear discussion of the difference between TypeForm[C] vs type[C], using examples we've discussed here, such as C | C (which can be assigned to TypeForm[C] because it is a valid spelling of the type C, but not to type[C] because it evaluates to a UnionType object at runtime, not the class object C) and C().__class__ (which can be assigned to type[C], presuming a type checker implements precise inference of __class__, because it evaluates to the class object C, but cannot be assigned to TypeForm[C] because it is not a valid type expression.)

Once we have that in the PEP, I think it would be useful to highlight this point (which I think may have escaped some readers) and solicit feedback on it in a Discourse thread from likely users of the PEP (e.g. the authors of runtime-typing libraries). If that feedback isn't strongly negative, I'll be happy going forward with the PEP in this form.

The outcome I would like to avoid is that we approve a version of the PEP, and only discover afterwards that the users who are most in need of the PEP weren't aware of this subtlety and are unhappy with the result.

[hmc-cs-mdrissi]

I’m unaware of good reason to support C().__class__ and am fine if that fails.

The main other reason I mentioned is some runtime type functions are designed to handle broad set of type annotations so will want to use TypeForm. Other runtime type functions may only handle things that are just type. The second type of function often does call first type of function. So ignoring backwards compatibility if I was writing all my runtime type code from scratch I’d still end up annotating most of my functions that accept TypeForm[T] as TypeForm[T] | type[T] to allow other functions that only handle type[T] to work. Some of my code handling TypeForm in it's generality (still with exceptions) does not mean all functions that build on that handle TypeForm too. The spirit of this earlier example,

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

# This function does not handle general typeforms, 
# but may use other functions that do.
def g(x: type[T]):
  f(x)
  x.mro()
  ...

is common. Or another example this one snipped from real code (just renames to keep generic + extra comments) ,

class Foo(Generic[T])
    @classmethod
    def get_input_schema_class(cls) -> type[T]: # This is expected to always be a concrete type.
        ...

...

config = to_config(self.get_input_schema_class(), ...)

to_config function is designed to handle types/annotations in general sense. It's callers though are free to be more restricted.

[carljm]

some runtime type functions are designed to handle broad set of type annotations so will want to use TypeForm. Other runtime type functions may only handle things that are just type. The second type of function often does call first type of function.

This makes sense, thank you; I understand this use case.

The "second kind" of function could also be annotated (if we had intersections) to take TypeForm & type, which would be a way of saying "I accept some valid type annotation, which also evaluates at runtime to an actual class object", and then it would be able to pass that argument along to a function that takes TypeForm without a problem.

It does still seem to me that there will be little or no practical value gained by having type[C] fail to assign to TypeForm[C] (because a function capable of handling a class object generally doesn't actually care whether that class object was named by an expression that isn't a valid type expression -- the theoretical distinction we have to make here is practically irrelevant to the function accepting a TypeForm), and it will make use of TypeForm for its intended purposes less convenient.

But I do now understand why it is more consistent/principled to define it this way, and there is a workaround available, and I don't like any of the consistent alternative versions of TypeForm I can think of, either. So as long as we don't have major objections from other likely users, I'm OK with this way of specifying it.

[erictraut]

I've posted a PR with the edits discussed above.

Summary of changes:

1. Attempted to clarify what is meant in the TypeForm specification by "syntactic, semantic, or contextual
   rules for type expressions".
2. Eliminated the special case subtyping relationship between type[T] and TypeForm[T].
3. Added a paragraph to the "Rejected Ideas" section explaining why type[T] is not considered a subtype of TypeForm[T].