mypy.subtypes

Undocumented

Undocumented

Find the type of member by 'name' in 'itype's TypeInfo.

Find the member type after applying type arguments from 'itype', and binding 'self' to 'subtype'. Return None if member was not found.

Undocumented

Detect whether a member 'name' is settable, whether it is an instance or class variable, and whether it is class or static method.

The flags are defined as following: * IS_SETTABLE: whether this attribute can be set, not set for methods and

non-settable properties;

• IS_CLASSVAR: set if the variable is annotated as 'x: ClassVar[t]';
• IS_CLASS_OR_STATIC: set for methods decorated with @classmethod or with @staticmethod.

Undocumented

Is the left compatible with the right, using the provided compatibility check?

is_compat:

The check we want to run against the parameters.

is_compat_return:

The check we want to run against the return type. If None, use the 'is_compat' check.

check_args_covariantly:

If true, check if the left's args is compatible with the right's instead of the other way around (contravariantly).

This function is mostly used to check if the left is a subtype of the right which is why the default is to check the args contravariantly. However, it's occasionally useful to check the args using some other check, so we leave the variance configurable.

For example, when checking the validity of overloads, it's useful to see if the first overload alternative has more precise arguments then the second. We would want to check the arguments covariantly in that case.

Note! The following two function calls are NOT equivalent:

is_callable_compatible(f, g, is_compat=is_subtype, check_args_covariantly=False) is_callable_compatible(g, f, is_compat=is_subtype, check_args_covariantly=True)

The two calls are similar in that they both check the function arguments in the same direction: they both run is_subtype(argument_from_g, argument_from_f).

However, the two calls differ in which direction they check things like keyword arguments. For example, suppose f and g are defined like so:

def f(x: int, *y: int) -> int: ... def g(x: int) -> int: ...

In this case, the first call will succeed and the second will fail: f is a valid stand-in for g but not vice-versa.

allow_partial_overlap:

By default this function returns True if and only if all calls to left are also calls to right (with respect to the provided 'is_compat' function).

If this parameter is set to 'True', we return True if there exists at least one call to left that's also a call to right.

In other words, we perform an existential check instead of a universal one; we require left to only overlap with right instead of being a subset.

For example, suppose we set 'is_compat' to some subtype check and compare following:

f(x: float, y: str = "...", *args: bool) -> str g(*args: int) -> str

This function would normally return 'False': f is not a subtype of g. However, we would return True if this parameter is set to 'True': the two calls are compatible if the user runs "f_or_g(3)". In the context of that specific call, the two functions effectively have signatures of:

f2(float) -> str g2(int) -> str

Here, f2 is a valid subtype of g2 so we return True.

Specifically, if this parameter is set this function will:

• Ignore optional arguments on either the left or right that have no corresponding match.
• No longer mandate optional arguments on either side are also optional on the other.
• No longer mandate that if right has a *arg or **kwarg that left must also have the same.

Note: when this argument is set to True, this function becomes "symmetric" -- the following calls are equivalent:

is_callable_compatible(f, g,

is_compat=some_check, check_args_covariantly=False, allow_partial_overlap=True)

is_callable_compatible(g, f,

is_compat=some_check, check_args_covariantly=True, allow_partial_overlap=True)

If the 'some_check' function is also symmetric, the two calls would be equivalent whether or not we check the args covariantly.

Undocumented

Check if left is a more precise type than right.

A left is a proper subtype of right, left is also more precise than right. Also, if right is Any, left is more precise than right, for any left.

Is left a proper subtype of right?

For proper subtypes, there's no need to rely on compatibility due to Any types. Every usable type is a proper subtype of itself.

If erase_instances is True, erase left instance after mapping it to supertype (this is useful for runtime isinstance() checks). If keep_erased_types is True, do not consider ErasedType a subtype of all types (used by type inference against unions).

Check whether 'left' implements the protocol 'right'.

If 'proper_subtype' is True, then check for a proper subtype. Treat recursive protocols by using the 'assuming' structural subtype matrix (in sparse representation, i.e. as a list of pairs (subtype, supertype)), see also comment in nodes.TypeInfo. When we enter a check for classes (A, P), defined as following:

class P(Protocol):
    def f(self) -> P: ...
class A:
    def f(self) -> A: ...

this results in A being a subtype of P without infinite recursion. On every false result, we pop the assumption, thus avoiding an infinite recursion as well.

Is 'left' subtype of 'right'?

Also consider Any to be a subtype of any type, and vice versa. This recursively applies to components of composite types (List[int] is subtype of List[Any], for example).

type_parameter_checker is used to check the type parameters (for example, A with B in is_subtype(C[A], C[B]). The default checks for subtype relation between the type arguments (e.g., A and B), taking the variance of the type var into account.

Undocumented

Undocumented

Return t minus s for runtime type assertions.

If we can't determine a precise result, return a supertype of the ideal result (just t is a valid result).

This is used for type inference of runtime type checks such as isinstance(). Currently this just removes elements of a union type.

Try to unify a generic callable type with another callable type.

Return unified CallableType if successful; otherwise, return None.