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

[Guido van Rossum]

On 4/29/07, Talin <talin at acm.org> wrote:
> 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.

Not entirely true in the latest incarnation -- the proposed
overloading of isinstance() and issubclass() will make it possible to
add Ring-ness to float and int as an afterthough from a user-defined
class.

> 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 that's the criterion (and I agree) it should be fairly obvious by
now that Ring and MonoidUnderPlus and everything in between should be
cast out, and we should stick with high school math. (Just note that
Travis Oliphant, Mr. NumPy Himself, pretty much confessed being
confused by the algebra stuff).

> 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.

So how about we reduce the scope of our (!) PEP (or perhaps of a new
one) to two items: (a) add @abstractmethod, and (b) overload
isinstance() and issubclass()? Library authors can do everything they
want with those, and we can always add a specific set of ABCs for
containers and/or numbers later in the 3.0 development cycle.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)