Idea: allow description of type-effect for functions that return bool

[elazarg]

I often encounter situations where I would like to extract some test into a function, but then mypy will not understand the implication on the types of the arguments. This goes against the intention that type checking will guide the programmer towards writing more readable code.

Similar case is functions like callable as in #1973, which requires hard coding so that mypy will understand.

I suggest a @type_effect decorator, possibly something along these lines:

@type_effect(true='x <: Callable')
def callable(x: object) -> bool: ...

Although the syntax is of secondary in this case.

[gvanrossum]

I think this idea is similar to what TypeScript calls "User-Defined Type Guards" (see https://www.typescriptlang.org/docs/handbook/advanced-types.html).

[elazarg]

Nice, I didn't notice that.

(Returning a type predicate is a cool idea, but the closest I can think of to type predicates in Python is a string :) )

Thinking about it this way, I must note that a type guard is a dependently-typed function, as hinted by the fact that it's hard to describe with eagerly-evaluated annotations: the type of the result (an assertion on x) depends on the value of x. But I think it should not be so hard to implement.

[ddfisher]

Another similar language feature we could emulate (as suggested by @FuegoFro) is contract annotations.

[elazarg]

What is the difference between contracts and dependent types, as far as typing goes?

[elazarg]

This feature will also be helpful for equality, since we can assume that if x==y then x and y have the same type. So mypy can infer more precise types when a branch is taken, and emit a warning when the types of x and y are incompatible (i.e. neither can be downcast to the other).

[gvanrossum]

But it's easy to override __eq__ so that x and y of different type can still be equal, and many classes use this.

[JukkaL]

For example, decimal.Decimal(1) == 1 is true.

[elazarg]

Indeed. But correct me if I'm wrong, it's mainly among related classes, so if I know the class is numeric, I will know its signature only promises that the other is also numeric. And if I don't know the actual class, then probably no harm done since I will not "downcast" the types too much.

[JukkaL]

But Decimal and int are not closely related at type level -- neither is a subtype of the other. The stubs for decimal use union types to specify that int and Decimal can be mixed in operations, but that's about it.

There is really no concept corresponding to 'numeric' in the type system. Such a thing would likely be quite tricky to define in a useful/sound way, because of complications around subtyping and the semantics of operator methods such as __add__.

User-defined classes can define __eq__ in completely ad-hoc ways, and they probably at least occasionally do this.

[DustinWehr]

@JukkaL you could close this in favour of #5206, which though newer has more discussion.

[JukkaL]

Closing in favor of #5206.