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

[Talin]

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 
about the discussion.

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 
add-on library.

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