I'm guessing you wrote code that looked roughly like this?

class Matrix:
    T = TypeVar('T')

    def _matrix_map(self, mapper: Callable[[Tile], T]) -> Dict[Coordinate, T]:
        # ...snip...

There's actually no issue with this at runtime/no issue for mypy, but it seems pylint isn't happy with you putting that "T" inside the scope of the class definition. What you can do to satisfy pylint is to instead do this:

T = TypeVar('T')

class Matrix:
    def _matrix_map(self, mapper: Callable[[Tile], T]) -> Dict[Coordinate, T]:
        # ...snip...

This is exactly equivalent to the former code snippet, and will also satisfy pylint.

(As a tangent, I'd argue that the fact that pylint isn't happy with the former is actually a bug. To be fair though, there aren't really any established style guides on best practices for type hints yet/putting a typevar inside of a nested scope is a somewhat uncommon use case, so I guess I can't really blame them for not accounting for this case.)

The only downside is that having that TypeVar on the outside does seem vaguely untidy/seems like it'll pollute the global namespace. You can partially mitigate this by renaming it to something like _T for example, to indicate it's private. You can also reuse this typevar whenever you need another generic class or function, which should also hopefully help keep the namespace pollution down.

For more information about using generics with Python type hints, see http://mypy.readthedocs.io/en/stable/generics.html

There is already a way to help out type checkers in ambiguous cases, use PEP 526 variable annotations for the result:

def to_list(value: Iterable[T] | T) -> list[T]:
    ...

def func1(x: list[int] | int):
    y: list[int] = to_list(x)
    reveal_type(y)

Most type checkers are capable of using this extra information during type inference, e.g. mypy calls this type context and pyright calls it bidirectional interface.

In the specific case of the to_list example, especially if you look at the proposed implementation in the linked issue, you're actually better served with overloads:

@overload
def to_list(value: Iterable[T]) -> list[T]: ...
@overload
def to_list(value: T) -> list[T]: ...

Type variables are literally "variables for types". Similar to how regular variables allow code to apply to multiple values, type variables allow code to apply to multiple types.
At the same time, just like code is not required to apply to multiple values, it is not required to depend on multiple types. A literal value can be used instead of variables, and a literal type can be used instead of type variables – provided these are the only values/types applicable.

Since the Python language semantically only knows values – runtime types are also values – it does not have the facilities to express type variability. Namely, it cannot define, reference or scope type variables. Thus, typing represents these two concepts via concrete things:

• A typing.TypeVar represents the definition and reference to a type variable.
• A typing.Generic represents the scoping of types, specifically to class scope.

Notably, it is possible to use TypeVar without Generic – functions are naturally scoped – and Generic without TypeVar – scopes may use literal types.

Consider a function to add two things. The most naive implementation adds two literal things:

def add():
    return 5 + 12

That is valid but needlessly restricted. One would like to parameterise the two things to add – this is what regular variables are used for:

def add(a, b):
    return a + b

Now consider a function to add two typed things. The most naive implementations adds two things of literal type:

def add(a: int, b: int) -> int:
    return a + b

That is valid but needlessly restricted. One would like to parameterise the types of the two things to add – this is what type variables are used for:

T = TypeVar("T")

def add(a: T, b: T) -> T:
    return a + b

Now, in the case of values we defined two variables – a and b but in the case of types we defined one variable – the single T – but used for both variables! Just like the expression a + a would mean both operands are the same value, the annotation a: T, b: T means both parameters are the same type. This is because our function has a strong relation between the types but not the values.

While type variables are automatically scoped in functions – to the function scope – this is not the case for classes: a type variable might be scoped across all methods/attributes of a class or specific to some method/attribute.

When we define a class, we may scope type variables to the class scope by adding them as parameters to the class. Notably, parameters are always variables – this applies to regular parameters just as for type parameters. It just does not make sense to parameterise a literal.

#       v value parameters of the function are "value variables"
def mapping(keys, values):
    ...

#       v type parameters of the class are "type variables"
class Mapping(Generic[KT, VT]):
    ...

When we use a class, the scope of its parameters has already been defined. Notably, the arguments passed in may be literal or variable – this again applies to regular arguments just as for type arguments.

#       v pass in arguments via literals
mapping([0, 1, 2, 3], ['zero', 'one', 'two', 'three'])
#       v pass in arguments via variables
mapping(ks, vs)

#          v pass in arguments via literals
m: Mapping[int, str]
#          v pass in arguments via variables
m: Mapping[KT, VT]

Whether to use literals or variables and whether to scope them or not depends on the use-case. But we are free to do either as required.

According to PEP-484, the right way to do this is to use Type[T] for the argument:

from typing import TypeVar, Type


T = TypeVar('T')

def my_factory(some_class: Type[T]) -> T:
    instance_of_some_class = some_class()
    return instance_of_some_class

It however seems like my editor does not (yet) support this.

Unfortunately no. First, something like Union[...] isn't valid to pass to a function accepting type - that only accepts actual classes. The solution to that is likely a new typing construct - TypeForm. The PEP for that is still in draft stage though. Secondly Union[*Ts] isn't supported itself. This was mentioned in early versions of the TypeVarTuple PEP, but was removed due to the limited number of use cases and implementation complexity required.

Not sure what your question is, the code you posted is perfectly valid Python code. There is typing.Type that does exactly what you want:

from typing import Type, TypeVar

class Animal: ...
class Snake(Animal): ...

T = TypeVar('T', bound=Animal)

def make_animal(animal_type: Type[T]) -> T:
    return animal_type()

reveal_type(make_animal(Animal))  # Revealed type is 'main.Animal*'
reveal_type(make_animal(Snake))   # Revealed type is 'main.Snake*'

See mypy output on mypy-play.

Python >= 3.8

As of Python3.8 there is typing.get_args:

print( get_args( List[int] ) ) # (<class 'int'>,)

PEP-560 also provides __orig_bases__[n], which allows us the arguments of the nth generic base:

from typing import TypeVar, Generic, get_args

T = TypeVar( "T" )

class Base( Generic[T] ):
    pass

class Derived( Base[int] ):
    pass

print( get_args( Derived.__orig_bases__[0] ) ) # (<class 'int'>,)

Python >= 3.6

As of Python 3.6. there is a public __args__ and (__parameters__) field. For instance:

print( typing.List[int].__args__ )

This contains the generic parameters (i.e. int), whilst __parameters__ contains the generic itself (i.e. ~T).

Python < 3.6

Use typing_inspect.getargs

Some considerations

typing follows PEP8. Both PEP8 and typing are coauthored by Guido van Rossum. A double leading and trailing underscore is defined in as: "“magic” objects or attributes that live in user-controlled namespaces".

The dunders are also commented in-line; from the official repository for typing we can see:

• "__args__ is a tuple of all arguments used in subscripting, e.g., Dict[T, int].__args__ == (T, int)".

However, the authors also note:

• "The typing module has provisional status, so it is not covered by the high standards of backward compatibility (although we try to keep it as much as possible), this is especially true for (yet undocumented) dunder attributes like __union_params__. If you want to work with typing types in runtime context, then you may be interested in the typing_inspect project (part of which may end up in typing later)."

I general, whatever you do with typing will need to be kept up-to-date for the time being. If you need forward compatible changes, I'd recommend writing your own annotation classes.