[Edu-sig] new python // and /

[Paul D. Fernhout]

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
>