Comment on PEP-0238

[John Machin]

Paul Prescod <paulp at ActiveState.com> wrote in message news:<mailman.994016102.30019.python-list at python.org>...
> I really don't want to go through this whole argument again (after all,
> that's the point of PEPs) but when you were a child, you "just knew"
> whether you meant truncating or float division. Python guesses based on
> the types of the operands which is a poor choice in a dynamically typed
> language that otherwise treats "5.0" as a more verbose alternate syntax
> for "5":
> 
> for i in range(5.0): 
> 	print i
> 
> If Python were to always disallow integer/float coercion then users
> would learn that and life would go on. Instead, it coerces in some
> places and not others.

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
>>> range(5.0)
[0, 1, 2, 3, 4]
-- as advertised by Paul. However doc says args are "plain integers".
>>> range(5.9999)
[0, 1, 2, 3, 4]
-- should maybe have a last value of 5 (see doc).
>>> range(5.99999999999999999)
[0, 1, 2, 3, 4, 5]
-- Tim seems to need to spend a lot more time explaining this sort of
thing to newbies than why 1/3 produces 0
>>> range(5+0j)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can't convert complex to int; use e.g. int(abs(z))
-- Not consistent with the theory espoused elsewhere in the PEP-0208
thread that ints are a subset of floats. Floats are a subset of
complex numbers.

IMO, narrowing coercions, ones that can silently lose information,
like the far-too-helpful automatic conversion from character to
numeric that's found in awk and Perl, are dangerous and are against
what I thought was the Python way. Certainly range(5.9999) is a dark
corner that I suspect most people had never ventured into.