Comment on PEP-0238

[Robert J. Harrison]

Paul Prescod wrote: 
> "Robert J. Harrison" wrote:
> > Python does not undermine the distinction between integers and floats.
> >>> 5 + 10
> 15
> >>> 5 + "10"
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: number coercion failed

You seem to want to have the string "10" automatically
converted to be an integer.  PEP-0238 will have no
impact on this. 

Python extensively distinguishes between numeric
types and other types.  Consider all of the special
class methods devoted to this end (.e.g, __add__).
It would not be too hard to creat a numeric string
that could behave to your satisfaction.

> > Arithmetic expressions that
> > involve only integers currently always result in an integer.
> >>> import math
> >>> math.cos(5)
> 0.28366218546322625

Cosine is not an arithmetic operation; it is a trigonometric
function.  Again, PEP-0238 would not change this behaviour
and would not increase consistency with it since in this instance
it is a property of the function (give it a real number and it gives
you float) not of the type of the argument (other than requiring
the real number property).

> ... Only people with a history in statically
> typed languages seem to expect operations to be type-consistent.

One of the great virtues of Python is indeed dynamic typing,
and I am not struggling to preserve type consistency.  I do think
that the current behaviour is more consistent with the properties
of mathematical integers, and for this reason I have had no trouble
in communicating to students the expected behaviour.
 
My comments have been directed at 

  - the assumption that the change will help beginners. I believe
    this to be incorrect - the PEP merely moves the point at which 
    they must appreciate the difference between integer and 
    floating point arithmetic.   

  - the amount of code that is broken

Hinsen and others have noted that functions written to expect a 
floating point argument will behave more consistently if they
are mistakenly given an integer argument.  The PEP will indeed
accomplish this.  But so would other far less drastic mechanisms.

You cite an example above.  cos(5) does the "right" thing.  It
is a property of the function itself, not the argument 
passed to it.  But cos("5") also (correctly in my view) gives a 
type error.

> > Who expects?  You are already seeing in this discussion that many
> > people think that the current behaviour is not only what they expect
> > but is actually very justifiable.
> 
> Sure, people with a bunch of programming language experience.
> 
> http://www.python.org/doc/essays/cp4e.html

This issue is only mentioned in passing in this article and no
reference is given to an actual survey.  Can U please post a better
link to the reference?  All I can find on Prof. Pausch's
home page or with a Google search are either third party notes from a 
Python conference or papers on Alice that again only touch on this
issue in passing.  I'm a big fan of Alice, so I know he knows about 
usability, but I'd like to see his description of how the survey 
was conducted and his conclusions.

The audience for Python is very large.  A survey that captures only
just a small part of that audience (e.g., novices focussing not on
programming but on 3-D graphics) is not necessarily a basis for change.
My experience with scientifically literate programming novices is also
not 
representative of the entire Python user community.  Hence the debate.

> > 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.
> 
> If you are consistent about this I might support you. Let's ban
> expressions like this:
> 
> >>> 1/2.0
> 0.5
> 
> Then Python will be consistent about the fact that integers and floats
> are as different as strings and integers.

Integers and floats are both numbers - hence 1/2.0 makes sense and the
Python coercion rules handle the choice of the type of the result. 
 
Integers are a subset of floats - so the Python choice of coercing 
integers to floats in mixed integer-float expression makes sense.

Integers have properties that most floats do not - so forcing the
coercion
of integers to floats in *some* pure integer expressions is a matter
of choice.  It is only this choice that PEP-0238 is addressing.
 



-------------------------------------------------------------------
"A foolish consistency is the hobgoblin of little minds, adored by 
little statesmen and philosophers and divines. With consistency a
great soul has simply nothing to do. He may as well concern himself
with his shadow on the wall. Speak what you think now in hard
words, and to-morrow speak what to-morrow thinks in hard words again,
though it contradict every thing you said to-day."

Ralph Waldo Emerson 
-------------------------------------------------------------------
-- 
Robert J. Harrison (rjh at 3-cities.com)