On 4/25/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Jeffrey, is there any way you can drop the top of the tree and going > > straight from Number to Complex -> Real -> Rational -> Integer? These > > are the things that everyone with high school math will know. > > I think yes, if you can confirm that the > import numbers > class Ring(AdditiveGroup): ... > numbers.Complex.__bases__ = (Ring,) + numbers.Complex.__bases__ > hack I mention under IntegralDomain will make isinstance(int, Ring) return > True.
Hm... That would require built-in types to be mutable (by mere mortals) which would kill the idea of multiple interpreters. AFAIK the only user of multiple interpreters is mod_python, which is a pretty popular Apache module... (Google claims 1.8M hits, vs. 5.66M for mod_perl, the market leader.) I guess the alternative would be to keep the mathematical ones in but make it so that mere mortals (among which I count myself :) never need to know about them. Sort of like metaclasses, for most people. But this still presents a bit of a problem. If we insist that built-in types are immutable, whenever a mathematician needs a new kind of algebraic category (you mention a few in the PEP), they have no way to declare that int or float are members of that category. They could write things like class MyFloat(float, DivisionRing): pass but this would be fairly painful. I would like to let users modify the built-ins, but such changes ought to be isolated from other interpreters running in the same address space. I don't want to be the one to tell the mod_python community they won't be able to upgrade to 3.0... > Do you want "Number" to be equivalent to Ring+Hashable (or a > Haskell-like Ring+Hashable+__abs__+__str__)? I don't think a "Number" > class is strictly necessary since people can check for Complex or Real > directly, and one of those two is probably what they'll expect after > knowing that something's a number. Fair enough, you could start with Complex. > Also, I don't see much point in putting Rational between Real and > Integer. The current hierarchy is Real (int, float, Decimal, rational) > :> Integer (int) and Real :> FractionalReal (float, Decimal, > rational), but Integer and FractionalReal are just siblings. Why? Why not have a properfraction() on Integer that always returns 0 for the fraction? The current math.modf() works just fine on ints (returning a tuple of floats). And why distinguish between Real and FractionalReal? What's the use case for reals that don't know how to compute their fractional part? > I'm wondering how many people are writing new numeric types who don't > know the abstract algebra. It's easy to know the algebra without recalling the terminologies. Lots of programmers (myself included!) are largely self-taught. > I think we should be able to insulate > people who are just using the types from the complexities underneath, > and the people writing new types will benefit. Or will seeing "Ring" > in a list of superclasses be enough to confuse people? Shouldn't only mathematicians be tempted to write classes deriving from Ring? Everyone else is likely to subclass one of the more familiar types, from Complex onwards. PS. I've checked your PEP in, as PEP3141. We might as well keep a fairly complete record in svn, even if we decide to cut out the algebraic foundational classes. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
