[Fwd: Comment on PEP-0238]
chris.gonnerman at newcenturycomputers.net
Sun Jul 8 15:42:51 CEST 2001
----- 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
> > when division is attempted, and likewise converting longs to floats when
> > dividing one by the other, but I really think we gain nothing by
> > 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
I'm saying. "Promotion" of long to float when one of each is in the
> > I would also say that, when longs and ints are divided together, you
> > probably promote the int to a long rather than performing float
> 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
> use x div y to force integer result or float(x)/y to force float
So the final operator for int division will be 'div'? Seems fine to me.
More information about the Python-list