Comment on PEP-0238

[Robert J. Harrison]

Paul Prescod <paulp at ActiveState.com> wrote in message news:<mailman.994084684.19932.python-list at python.org>...
> ... Most people do not expect these four
> expressions to yield different results:
> 
> 1.0/3.0
> 1/3
> 1.0/3
> 1/3.0

I completely disagree, and as someone who has taught math, science and
programming, it is quite clear to me that the distinction between integer
and real arithmetic is an essential concept.

> ... Why is automatic coercion *ever* necessary? 

Mixed type expressions are almost inevitable.  It would take a much 
larger reworking of the Python numerical model than proposed by
PEP-0238 to do away with that.  The existence of the standard 
__coerce__ method illustrates the importance of such expressions.

> >      For instance, the new proposal sensibly does not suggest that lists
> >      should support real indices,
> 
> 	That might well be an implication of PEP 228.

I might accept an argument that says that anything that coerces 
(automatically!) to an integer with no loss of precision can be 
used to index a list.  But how to distinguish between 1, 1+eps 
(eps=machine precision), and 1.1?  How many elements are there
between elements [1] and [2]?


> >      ... however simple expressions such
> >      as a[i/3] would have to be coded as a[int(i/3)] or a[i//3]
> >      in order to be sure to avoid a type error.
> 
> You mean that you would have to say exactly what you mean according to
> the new syntax. That's hardly a legitimate argument against the syntax.
> "If you add a 'function' keyword, I would have to precede my function
> calls with it." Well, yeah, that's the point of adding new syntax.

My point was rather poorly made.  The new
proposal has simply moved the point at which people need to understand
the distinction between real and integer arithmetic.  Currently it must
be understood when the operation is performed.  In the new proposal it
must be understood when the result of the operation is used.