Unknown Types

Currently, it is not possible to infer the type parameters to generic functions incertain situations:

defmake_list[T](*args:T)->list[T]:...reveal_type(make_list())# type checker cannot infer a meaningful type for T

Making instances ofFunctionType subscriptable would allow for this constructor tobe typed:

reveal_type(make_list[int]())# type is list[int]

Currently you have to use an assignment to provide a precise type:

x:list[int]=make_list()reveal_type(x)# type is list[int]

but this code is unnecessarily verbose taking up multiple lines for a simple functioncall.

Similarly,T in this example cannot currently be meaningfully inferred, sox isuntyped without an extra assignment:

deffactory[T](func:Callable[[T],Any])->Foo[T]:...reveal_type(factory(lambdax:"Hello World"*x))

If function objects were subscriptable, however, a more specific type could be given:

reveal_type(factory[int](lambdax:"Hello World"*x))# type is Foo[int]

Undecidable Inference

There are even cases where subclass relations make type inference impossible. However,if you can specialise the function type checkers can infer a meaningful type.

deffoo[T](x:Sequence[T]|T)->list[T]:...reveal_type(foo[bytes](b"hello"))

Currently, type checkers do not consistently synthesise a type here.

Unsolvable Type Parameters

Currently, with unspecialised literals, it is not possible to determine a type forsituations similar to:

deffoo[T](x:list[T])->T:...reveal_type(foo([]))# type checker cannot infer T (yet again)

reveal_type(foo[int]([]))# type is int

It is also useful to be able to specify in cases in which a certain type must be passedto a function beforehand:

words=["hello","world"]foo[int](words)# Invalid: list[str] is incompatible with list[int]

Allowing subscription makes functions and methods consistent with generic classes wherethey weren’t already. Whilst all of the proposed changes can be implemented usingcallable generic classes, syntactic sugar would be highly welcome.

Due to this, specialising the function and using it as a new factory is fine

make_int_list=make_list[int]reveal_type(make_int_list())# type is list[int]

Monomorphisation and Reification

This proposal also opens the door tomonomorphisation andreified types.

This would allow for a functionality which anecdotally has been requested many times.

Please note this feature is not being proposed by the PEP, but may be implemented inthe future.

The syntax for such a feature may look something like:

deffoo[T]():returnT.__value__assertfoo[int]()isint

Setting__orig_class__

Currently,__orig_class__ is an attribute set inGenericAlias.__call__ to theinstance of theGenericAlias that created the called class e.g.

classFoo[T]:...assertFoo[int]().__orig_class__==Foo[int]

Currently,__orig_class__ is unconditionally set; however, to avoid potentialerasure on any created instances, this attribute should not be set if__origin__ isan instance of any function object.

The following code snippet would fail at runtime without this change as__orig_class__ would bebar[str] and notFoo[int].

defbar[U]():returnFoo[int]()assertbar[str]().__orig_class__==Foo[int]

Interactions with@typing.overload

Overloaded functions should work much the same as already, since they have no effect onthe runtime type. The only change is that more situations will be decidable and thebehaviour/overload can be specified by the developer rather than leaving it to orderingof overloads/unions.