# [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

Talin talin@acm....
Sun Apr 29 19:11:44 CDT 2007

```Guido van Rossum wrote:
> Maybe we should stop trying to capture radically different
> mathematical number systems using classes or types, and limit
> ourselves to capturing the systems one learns in high school: C, R, Q,
> Z, and (perhaps) N (really N0). The concrete types would be complex <:
> C, float<:R, Decimal<:R, int<:Z. NumPy would have many more. One could
> argue that float and Decimal are <:Q, but I'm not sure if that makes
> things better pragmatically; I guess I'm coming from the old Algol
> school where float was actually called real (and in retrospect I wish
> I'd called it that in Python). I'd rather reserve membership of Q for
> an infinite precision rational type (which many people have
> independently implemented).

I haven't really been following this discussion, given my lack of
understanding of the issues involved, but I want to make one observation

Normally, when someone suggests an idea for a major addition to Python
of this scope, the standard response is that they should go develop it
as a 3rd-party package and see if becomes popular, and if it does it can
be considered for inclusion in the standard library.

Unfortunately, we are somewhat constrained in this case, because we're
talking about altering the behavior of some fairly fundamental built-in
types - which means that it's going to be hard to implement it as an

And yet, it seems to me that this particular set of features really does
need a long gestation period compared to some others that we've
discussed. Most of the 3000-series PEPs are really about a fairly small
set of base decisions. Even the long PEPs are more about descriptions of
the logical consequences of those decisions than about the decisions
themselves. The ABC PEPs are different, in that they are standardizing a
whole slew of things all at once. Moreover, I think there is a real
danger here of a kind of ivory-tower decision making, isolated from
day-to-day writing of applications to keep them grounded.

The question of whether to limit to the "high school" number classes, or
to go with the more mathematically abstract set of things is a decision
which, it seems to me, ought to be made in the context of actual use
cases, rather than abstract theorizing about use cases. (I'm also
generally supportive about copying what other languages have done, on
the theory that they too have been tested by real-world use.)

If it were technically possible, I would recommend that this PEP have to
run the same gauntlet that any other large library addition would, which
is to go through a long period of community feedback and criticism,
during which a large number of people actually attempt to use the
feature for real work. I also think, in this case, that the special
power of "core python developer fiat" should not be invoked unless it
has to be, because I don't think that there is a firm basis for making
such a judgment yet.

I would also suggest that some thought be given to ways to allow for
experimentation with different variations of this feature. If it is not
possible to make these numeric classes definable in Python at runtime,
then perhaps it is possible instead to allow for custom builds of the
Python 3000 executable with different arrangements and configurations of
these built-in classes.

-- Talin
```