PEP 238 (revised)

[Guido van Rossum]

"Terry Reedy" <tjreedy at home.com> writes:

> >This makes expressions expecting float or complex
> >     results error-prone when integers are not expected but possible
> as
> >     inputs.
> 
> and vice versa for integer expressions getting float input

That's not the same argument -- expressions expecting ints are
generally broken when they receive floats; expression expecting floats
are *only* broken when they receive ints IF THEY USE DIVISION.  The
PEP cannot do anything about floats passed in where ints are expected
-- such usage is broken.

> > Semantics of True Division
> >
> >     True division for ints and longs will convert the arguments to
> >     float and then apply a float division.  That is, even 2/1 will
> >     return a float (2.0), not an int.
> 
> Given that one spurious argument for this proposal was the claim that
> float division preserves more information than quotient division, I
> think it might be appropriate to warn here that the opposite is true
> for sufficiently long longs, so that one may need to switch to
> long//long to preserve accuracy.

I never bought the "preserving information" argument.  In general all
classic use of long/long should be switched to long//long, of course,
as should all classic use of int/int.

> >     - It has been proposed to call // the quotient operator.  I like
> >       this.  I might rewrite the PEP to use this if enough people like
> >       it.  (But isn't the assumption that this truncates towards
> >       zero?)
> 
> Its true that -8/3 = -(2+2/3), but I think divmod(-i,j)[0] is up for
> grabs in most people's mental space.  This concern never entered my
> mind until I read the above.

Good!

> ---
> The only way I can think of to 'globally' turn on new division on my
> own Windows computer is to rebind .py and .pyc to python.bat
> containing '...python.exe -Dnew'.

Do I need to add that to the PEP?

> Great revision!

Thanks.

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