[Python-ideas] Python Numbers as Human Concept Decimal System

[Andrew Barnert]

From: Mark H. Harris <harrismh777 at gmail.com>
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.