Closed
Description
It's not clear what's the best way to deal with numbers.Integral
, numbers.Real
, etc. Various issues are discussed in python/typeshed#464.
Some relevant questions:
- Should
int
be a subclass ofIntegral
(and similarly forfloat
/Real
)? If yes, how should we annotate the stubs? (Let's focus on__add__
and__radd__
-- other operators are probably similar.) - Should stubs prefer
Integral
andReal
toint
andfloat
whenever feasible? Many stdlib functions only accept concreteint
orfloat
instances, so using them everywhere wouldn't be safe. - Should we recommend user code to use
int
orIntegral
by default? If we don't have a consistent convention, integrating codebases that use different conventions could become painful, asIntegral
should almost certainly not be a subtype ofint
. - Can we find examples of some typical use cases where just using
int
/float
is not sufficient andIntegral
/Real
could help? How common and important are these use cases? - If (1) is blocked by limitations of the type system, should we look at extending to the type system to better support abstract numeric types? What are the current limitations?
- If (1) or (2) requires compromising some type safety, are the gains important enough to make this a worthwhile tradeoff?