Description
With regards to the numeric tower, PEP 484 states:
PEP 3141 defines Python’s numeric tower, and the stdlib module
numbers
implements the corresponding ABCs (Number
,Complex
,Real
,Rational
andIntegral
). There are some issues with these ABCs, but the built-in concrete numeric classescomplex
,float
andint
are ubiquitous (especially the latter two :-).Rather than requiring that users write
import numbers
and then usenumbers.Float
etc., this PEP proposes a straightforward shortcut that is almost as effective: when an argument is annotated as having typefloat
, an argument of typeint
is acceptable; similar, for an argument annotated as having typecomplex
, arguments of typefloat
orint
are acceptable. This does not handle classes implementing the corresponding ABCs or thefractions.Fraction
class, but we believe those use cases are exceedingly rare.
This is a very useful passage to link to, because:
- It clearly (albeit tersely) states that the PEP-3141 ABCs are problematic
- It clearly states the separate solution that PEP-484 proposes for dealing with numeric types
- It frames the PEP-484 solution in opposition and contrast to the PEP-3141 solution
The parallel passage in the typing spec currently states this:
Python’s numeric types
complex
,float
andint
are not subtypes of each other, but to support common use cases, the type system contains a straightforward shortcut: when an argument is annotated as having typefloat
, an argument of typeint
is acceptable; similar, for an argument annotated as having typecomplex
, arguments of typefloat
orint
are acceptable.
Since PEP-484 is a historical document rather than a piece of living documentation, it would be great if the typing spec could state as clearly as PEP-484 that the PEP-3141 ABCs are not the recommended way of annotating numeric types in Python, and that type checkers may not necessarily (and in fact probably won't ever) support them.