Comment on PEP-0238

[Paul Prescod]

"Robert J. Harrison" wrote:
> 
> 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.  

That's my *exact* point. Python strongly enforces the view that there
are "numbers", "strings".... not "integers", "floats", "strings"
Integers and floats are strongly related. Much more so than other types.

No, I do not want to change the behaviour of either of these lines. I'm
making the point that a threshold has been crossed. The distinction
between integers and floats has been blurred. The logical conclusion is
to treat integers as a special case of floats everywhere.

>...
> 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.

I don't see how we are talking about the fundamental properties of
integers. From my point of view, we're talking about the choice of
meaning for a symbol. Outside of a cultural context, the choice is
meaningless. As far as the mathematical construct "integers" are
concerned, we could as well use "/" to mean "to the power of".

> 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.

Once we've moved the point of confusion back, we can recognize the next
roadblock and move it back further. There are many other PEPs that
address other issues in the numeric model. This is one of them.

>   - the amount of code that is broken

No argument there.

> 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. 

cos(5) does the "right" thing because Python's C API is statically type
checked and it coerces integers to floats for the implementor
automatically. In other words, C programmers do the easiest thing and
get code that automatically coerces properly. Python programmers get no
such free ride. It takes extra care to write a function that treats
integers as a special case of float....but ONLY if it involves division.
If it involves multiplication or anything else, it isn't a problem.

> But cos("5") also (correctly in my view) gives a
> type error.

I agree that that's the right thing. Strings and integers are very
different in Python. Integers and floats are blurred together by the
implementation and the language semantics.

> ...
> 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.

I agree that I'd like to see more detail but I only know what he said at
the talk. Nevertheless, I don't really see it as useful to
over-emphasize that one data point. 

Let me offer the following concrete observation. Python is the *only*
dynamic language that I know of that makes this choice. JavaScript, Tcl,
Perl and (I think) Ruby, int/int -> float. In fact, most of the newer
languages always treat integers as integral floats (or in Ruby Integer
is a subclass of Numeric). Python is also the only language where people
complain about the division behaviour and have arguments about it every
six months. Consider that a massively distributed usability test. You
make integers a subset of floats and users are happy. You give them
different operations and you get perpetual Usenet filler.

There is only one humane choice. :)

>...
> 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.

I agree 100%. All I argue is that the choice for division should be
consistent with the choice made elsewhere to treat integers as a special
case of floats.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook