[Fwd: Comment on PEP-0238]

[Chris Gonnerman]

----- Original Message -----
From: "Guido van Rossum" <guido at python.org>


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

I remember that; I'd forgotten about that PEP.

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

No, I specifically don't want to change division of long by long; that's
what
I'm saying.  "Promotion" of long to float when one of each is in the
operation
is different.


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

Ah, so.

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

So the final operator for int division will be 'div'?  Seems fine to me.