[Fwd: Comment on PEP-0238]

[Guido van Rossum]

"Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> writes:

> Perhaps it's too inconsistent, but I see no reason why longs can't
> continue returning "normal" results forever.  When you use a long
> you know what you are doing, or at least think you do; so you should
> expect integer division results just as always.

Well, but there's another proposal (that taken by itself would have
few detractors) to blur the distinction between int and long.  This
would do away with the whole OverflowError problem: int calculations
whose result doesn't fit in an int would simply and silently return a
long instead.

This is PEP 237.  I don't expect that this will be added to Python 2.2
because there are lots of little details that need to be taken care
of, and backwards incompatibilities (e.g. 1<<100 currently yields 0,
but 1L<<100 is the same as 2L**100).

But given that that is likely to be the way of the future, it seems
best to treat int and long division the same way.

> What does it buy us to break longs as well as ints?
> 
> Overall I am in favor of *eventually* automatically promoting ints to float
> when division is attempted, and likewise converting longs to floats when
> dividing one by the other, but I really think we gain nothing by changing
> the semantics of division of longs.

This is inconsistent.  You are saying that you think we gain nothing
from something (long division) that you want to change anyway.

> I would also say that, when longs and ints are divided together, you should
> probably promote the int to a long rather than performing float division.

You're thinking of it the wrong way.  The operands are first converted
to the same type according to specific rules; then that type is asked
to perform the operation.  So what you are requesting here is already
decided, by the existing rule that says that in "int/long", the int is
converted to long before the operation takes place.

> I really don't think a newbie will appreciate
> 
>     >>> 1 / 2
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     IntDivisionError: integer division is invalid
> 
> any more than they currently understand
> 
>     >>> 1 / 2
>     0

Good point.  So we should switch directly from 1/2 -> 0 to 1/2 ->
0.5.  But it's unavoidable that they will get a warning in some
versions...  e.g.

    >>> 1 / 2
    __main__:1: DeprecationWarning: integer division semantics will change;
    use x div y to force integer result or float(x)/y to force float result
    0
    >>> 


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