On Thursday, March 6, 2014 11:48:53 AM UTC-6, Guido van Rossum wrote:{snip}
hi Guido, thanks for your responses, your candor, and your kindness; I thinkdialogue will work, and I promise to keep the rhetoric to a bare minimum, if at all. :)There really are only two questions I am going to try to answer here, and some ofthe answer goes back to Stefan's (and others) questions as well, so I hope its helpful.So, by context you really seem to be referring to some specific state of the program. Perhaps you are even talking about extending the existing notion of numeric context used by Python's Decimal type. But it's not very clear because "you change the context" is also a common term for changing the topic of a discussion.
This is what I mean by "context," for this entire discussion, mostly having to do withDecimal and the "context manager" and these two lines:getcontext()with localcontext(ctx=None) as context_managerAllow me to back up a bit... the pdeclib module was not difficult for me because of themathematics (no brag) I can code transcendental functions in my sleep. The hard part ofthat project last week was coming to grips with the context manger, and the parameterizationof context attributes in the Decimal class. Back in the day when I did this work for Rexx at IBMI used NUMERIC DIGITS and NUMERIC FUZZ to emulate (in a crude way) what Decimal isdoing correctly with its context, with the context manager. I credit Oscar Benjamin for helpingme get up to speed with this concept (and I am so glad he did too, because its key for thisentire discussion.Before we go on, allow me to explain my italics of Number and PythonNumber. These areeach an abstract base class. They are a class that is never instantiated, but from which allother "numbers" are derived as objects. (more below)I'm sorry, but I am *still* unsure about what you mean by "context". Python does not need a context object to switch between complex and real number processing -- it's all done through operator overloading.
(more on this below, but I am thinking beyond overloading/ actually, virtual functions and templates)Actually, modern Python is considered object-oriented.Thank you. This has everything to do with this discussion, but allow me to take a humorousbreak and relate an anecdote... I have had numerous discussions with T.R. and C.A and S.D. andothers where in the end python was object based. Ha! Nope, you have seen it right here, theBDfL says its "object oriented," and that's the end of the argument! (ok, tiny rhetoric)Unifying thenumber system on a computer does not have to be grounded in paradigms that serviced theindustry (and academy) for the past 40 years;{snip}
Now you've got a specific proposal and we can discuss pros and cons. This is a topic that comes up occasionally and it is indeed a pretty interesting trade-off. I suspect the large (and fast-growing) SciPy community would prefer to keep binary floating point, because that's what their libraries written in Fortran or C++ want, and extra binary/decimal conversions at the boundaries would just slow things down. But I'm really speculating here -- maybe they don't need high-performance conversion between binary and decimal, since (perhaps) they may do their bulk I/O in C++ anyway. Or maybe it varies per application.
Here is the main response for this discussion, and I will endeavor to keep therhetoric down, I promise.This may even be easier to accomplish in 3.x without breaking anyone, or any third party software either; dependsIn my view numbers are objects (like circles, squares and triangles; in polymorphism discussions).Numbers are nothing more than objects which have "contexts" just like circles and squares and trianglesare nothing more than objects that have "contexts". In the following discussion think in terms of objectoriented (as in Grady Booch) rather than any specific language--- and certainly not python syntax. um,think C++ for now, if you must think of any. A Number is an abstract base class with "context" attributesand pure virtual functions--- it will never be instantiated---and PythonNumber will derive from that; alsoan abstract base class. Here is the Class hierarchy I am proposing:NumberPythonNumberDecimalReal <======= this is the defaultBinaryIEEE85Real_b&c (...) omitted for clarityComplexQuaternionRationalFraction
&c--------------------------------------------------Well, there it is. The idea is that any function or method that takes a Number referenceor a PythonNumber reference does not have to interrogate what type of Number it is... it justworks (why?) glad you asked, because of polymorphism and a three pointer hop down a virtualfunction table!If a function or method gets a Number parm in as in method(num) then to get the prettyprint representation of the number is simply num.pretty_print(), or to get an evaluationof the number is num.eval(), or to get the string rep of the number is num.str()... and on and on.The point is that other parts of the system no longer need to know what "type" of number objectit is, the right code gets called because of virtual functions, operator overloading, and the beautifulvirtual function table (all under the covers, not MAGIC, but polymorphism).Python at present is disjointed when it comes to number as a concept. In my view numbersneed to be objects, and the Class hierarchy (see my simplified version above) needs to unify numbersacross the python boards (so to speak) so that "types" are only important to the implementors, andso that adding new "types" is easy, concise, and coherent.I realize that this suggestion is over the top in terms of size and weight (Stefan's concern above).But not really, when you think of conceptualizing the unification of numbers under Number andPythonNumber . There may be other kinds of numbers too, besides these... like maybe GmpyNumberof BC_Number, or others.The bottom line is that we have an object oriented language in front of us that has thesoftware engineering advantages which would allow this kind of hierarchy and conceptualizationof a unified number system. Let's leverage our technology for mutual advantage across pythoncommunities?Thanks for your consideration,Sincerely,Kind regards,marcus