On Fri, Mar 7, 2014 at 9:23 AM, Mark H. Harris email@example.com wrote:
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!
That's way too concrete for Pythonic style :)
All you need to do is have each numeric type implement the same operations, and there you are, as the Lord Chancellor said, out of your difficulty at once!
And that's what we already have. You can add two numbers and they'll simply add. In fact, a C++ style "hop down a virtual function table" couldn't handle that. I could make a class hierarchy like you describe, and have each one have an add() method or operator+(), but somewhere along the line, something still has to cope with the fact that it could be given any sort of number - there has to be code someplace that handles the adding of a (Decimal) Real and a Real_b, because some day, someone's going to do it. (The correct response might be to raise TypeError, on the basis that that action merges two separate inaccuracies. But more likely, the correct response is to convert one of them to the other type.)
What does your proposed hierarchy offer that numbers.Number doesn't?