-
Notifications
You must be signed in to change notification settings - Fork 279
Description
With regards to the numeric tower, PEP 484 states:
PEP 3141 defines Python’s numeric tower, and the stdlib module
numbersimplements the corresponding ABCs (Number,Complex,Real,RationalandIntegral). There are some issues with these ABCs, but the built-in concrete numeric classescomplex,floatandintare ubiquitous (especially the latter two :-).Rather than requiring that users write
import numbersand then usenumbers.Floatetc., this PEP proposes a straightforward shortcut that is almost as effective: when an argument is annotated as having typefloat, an argument of typeintis acceptable; similar, for an argument annotated as having typecomplex, arguments of typefloatorintare acceptable. This does not handle classes implementing the corresponding ABCs or thefractions.Fractionclass, 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,floatandintare 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 typeintis acceptable; similar, for an argument annotated as having typecomplex, arguments of typefloatorintare 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.