Comment on PEP-0238

[Guido van Rossum]

"Robert J. Harrison" <rjh at 3-cities.com> writes:

> Again, my major objection to this proposal is that it gives us
> nothing and breaks a lot of existing code.

Other educators disagree.  Take the case of VPython.

The VPython folks have used Python very successfully to teach freshman
physics students at Carnegie Mellon to create 3D models.  Many
students had little or no programming experience.  The goal of the
course wasn't to teach programming, it was to teach understanding of
physics.  Throughout the course, students were writing Python programs
implementibg various laws of physics.  Here's a quote from Bruce
Sherwood, one of the teachers (without permission, but I'm sure he
doesn't mind):

"""
The final activity (last week) was very satisfying. Students made a
traveling electromagnetic wave in 3D, and then moved a positron
relativistically (leaving a trail) under the influence of the
wave. Almost every student did a very nice job. This is way beyond
what is normally done in these courses. And remember that this was
with extremely little instruction, with a sizable minority of the
students never having written a program before entering our course.
"""

Now read his criticism of Python:

"""
Everything worked extremely well except for integer division, both 1/2
being zero and 10**-15 giving an execution error. For example, on last
week's program one student spent two hours trying to figure out why he
was getting a strange positron trajectory, and it finally turned out
to be (x+y)**(1/2), which looks fine but is equal to 1 for all values
of x and y.
"""

This exactly corroborates the experience of the Alice team (who
started this discussion).

> The proposal is based upon the supposition that uniting floats with
> integers makes programming easier to learn for beginners, but this
> is absolutely not consistent with my experience in teaching
> programming using Python and other languages (including Maple that
> has rationals).

No, the proposal intends to make *using* Python easier.  Now, clearly
there are some areas where the current approach (1/2 == 0) is more
useful, and other areas where the proposed new approach (1/2 == 0.5)
is more useful.  But I think that the latter rule is useful vastly
more often than the former.  There just are more places in life where
1/2 equals one half then where it equals zero.

Note that I'm not saying that 1/2 *returns* 0.5.  While in the current
proposal that's indeed the plan, I'm not necessarily against returning
something else, e.g. maybe a rational.  (I have a different reason to
dislike rationals and favor decimal arithmetic instead, but that's
quite a different discussion.)  I'm just saying that the *value* of
1/2 should be equal to the value of 0.5, in other words, 1/2 should
act like 0.5 when fed into a floating point expression

> All programmers must very soon appreciate the different nature of
> integer and floating point (or rational) arithmetic in order to
> address discretized quantities such as lists, files, strings, etc. 

Agreed.  And integers should remain required for indexing etc.  But
when dividing two integers, we shouldn't drop the remainder on the
floor by default.

--Guido van Rossum (home page: http://www.python.org/~guido/)