I would just like to point out that Python (compared to Smalltalk) http://www.smalltalk.org/articles/article_20041008_a1.html has always done division wrong, and the new approach still does division wrong, IMHO, from a mathematical (not implementation) perspective. :-) In a dynamic object system, especially one oriented towards beginners at all, the proper result from division of two whole numbers is a "fraction". Fractions can be represented as a special type of mathematical object different from either an integer or a floating point number, with the order of promotion when mixing various types being integer -> fraction -> floating point. Multiplying two fractions should still yield a fraction (unless it reduces, e.g. 3/5 * 5/3 --> 15 / 15 --> 1). Smalltalk has done this for twenty plus years. It's the way mathematicians work on the chalkboard (if any still do. :-) when working with equations and reducing terms. It lends itself to generalizations, like including units into expressions and reducing or multiplying units. if the mathematics library is written to be extensible. It's the way grade school math is taught. It avoids a loss of precision (converting, say, 2/3 to the imprecise 0.66666666666666663) until explicitly required (e.g. "float(2/3)"). If you want a float from a fraction, then in such a system you should generate it yourself, either by making one of the numbers a float (e.g. 3.0 / 5) or by taking the fractional result and converting it to a float ("float(3/5)"). Obviously "float(2/3)" in Python as it is now yields 0.0 not 0.59999999999999998. Python as a community is still stuck in an integer vs. floating point mindset left over from C, IMHO. Having said that, I don't necessarily think Guido is making the wrong decision for the overall Python community or language, e.g. his comments here: http://mail.python.org/pipermail/python-dev/2001-March/013587.html Just one example of how when a language goes down one path from a set of choices, it kind of gets stuck with them, and builds a community comfortable with those decisions (where others uncomfortable with them use other systems); the same is generally true for mailing lists about any topic :-). The bigger issue here is actually that in Smalltalk these sort of things are done by user accessible libraries, and so you could use a different math library or extend the current one without changing the language, whereas in Python (especially in the past) they are more under the covers hidden in C and built into the system, at least as far as is generally thought and discussed. Still, here is Python implementation of fractions done by Mike Hostetler: http://users.binary.net/thehaas/fractionpy.shtml (haven't tried it myself though.) So, it is possible. And as Python moves to more generally unified types and objects by default, stuff like that may be done more and more as more people think of it. And I think it would be nice for a standard to evolve for that, especially from a "using Python to teach mathematics" standpoint. Personally, I think that since one isn't going to be doing much serious number crunching computation in Python itself (compared to NumPy or some other library accessed through Python) that having fractions in Python isn't much of a performance issue in practice (more a coding style change if anything to be explicit about floats). But it certainly is a potential major compatibility issue, so I can see the argument for the current approach, although to be fair, any minor change affecting math is a major compatibility issue, and the current behavior of 2/3 == 0 is always surprising. It would seem problematical to beginners to need to learn yet another operator, yet another inconsistency, and so on, before it is needed; I have no problem by itself with a "//" operator, which is useful in special circumstances, as is one to yield a remainder, see for example: http://mail.python.org/pipermail/python-list/2001-August/060184.html So I think from a pedagogical point of view, getting kids to use "//" when "/" really should be OK at the start and maps onto the infix syntax they already know is at the very best an ugly necessity to gain other Python benefits, given how Smalltalk shows that operator is not needed for routine mathematics or for beginners. Still, given the current situation, I think your suggestion makes sense. --Paul Fernhout Andrew Harrington wrote:
As I gear up to write or translate lessons for Crunchy Frog, I would like feedback on one general issue: // -- the new integer division operator.
// is already legal in Python 2.4, though / still means the same thing for integers. That is to change in Python 2.5, that is already in alpha 2: / as integer division will able to be set to mean the old operator or always mean real division (I forget which is the default in 2.5).
I think this is an excellent change in Python. I would encourage using // for integer division in all newly written lessons. There is the issue in 2.4 that you still have to go through an extra cast if you want real division, x = 5 y = 3 real_quotient = float(x)/y
but there is nothing for that at the moment