On 4/29/07, Talin <talin@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/)