From: Mark H. Harris firstname.lastname@example.org Sent: Thursday, March 6, 2014 2:23 PM
Here is the Class hierarchy I am proposing:
Number PythonNumber Decimal Real <======= this is the default BinaryIEEE85 Real_b &c (...) omitted for clarity Complex Quaternion Rational Fraction &c--------------------------------------------------
This kind of hierarchy doesn't work. Most importantly, you can have complex decimal floats and complex binary floats. This is why complex is a class template rather than a class in C++. Also, this is ignoring the numerical tower—rationals are a specialization of reals, just as floats are.
Well, there it is. The idea is that any function or method that takes a Number reference or a PythonNumber reference does not have to interrogate what type of Number it is... it just works (why?) glad you asked, because of polymorphism and a three pointer hop down a virtual function table!
99% of the time you don't need these abstract base classes at all, because duck typing and operator overloading. But when you need it, it's already there, and does everything you're asking for. See below.
If a function or method gets a Number parm in as in method(num) then to get the pretty print representation of the number is simply num.pretty_print(), or to get an evaluation of the number is num.eval(), or to get the string rep of the number is num.str()...
We already have the first and third as str() and repr(), and I'm not sure what the second is supposed to do. What does evaluating a number return other than the number itself?
Python at present is disjointed when it comes to number as a concept. In my view numbers need to be objects, and the Class hierarchy (see my simplified version above) needs to unify numbers across the python boards (so to speak) so that "types" are only important to the implementors, and so that adding new "types" is easy, concise, and coherent.
This is all just plainly false. Numbers are objects. There is a hierarchy of abstract base classes for them—done correctly—in the numbers module. And they handle everything you're asking for, except for one thing: There are no ABCs to distinguish binary vs. decimal floats. But I doubt that's useful for anything. What kind of code can you imagine that does need to distinguish, say, float vs. decimal.Decimal, but doesn't need to distinguish decimal.Decimal from mylib.MyDecimal? They're both inexact floating-point representations of reals.
If the motivation for your whole idea is that you want a class hierarchy like the one in the numbers module but you didn't know that it already existed, then we're done.