Comment on PEP-0238

[Bengt Richter]

On 6 Jul 2001 16:17:39 -0700, aahz at panix.com (Aahz Maruch) wrote:

>In article <3dd77drkea.fsf at ute.cnri.reston.va.us>,
>Andrew Kuchling  <akuchlin at mems-exchange.org> wrote:
>>Guido van Rossum <guido at python.org> writes:
>>>
>>> 3. A revision later, we change all plain integer divisions to be an
>>>    error, *forcing* folks to use div() or use the future statement to
>>>    specify floating point division.
>>
>>Step 3 strikes me as a bit odd; does that mean documentation for that
>>release will have to say "applying the / operator to integers is an
>>error, full stop"?  And then in the next release the docs will again
>>have to be changed to say that integer division now works?  IMHO step
>>3 should be dropped; one release with a warning every time integer
>>division is attempted should be sufficient.
>
>I'm in agreement with Guido that at least two releases are necessary
>(I also agree that it could be two warning releases).  But I think
>Guido's step 3 (if used) should be changed to the semantically equivalent
>
>    In Python 2.4, integer division with the '/' operator raises an
>    exception.  This exception can be caught as usual, but the
>    programmer should prepare for the next release of Python by either
>    using the div() function or by using the future directive to get
>    floating point division.
>
>(Calling it an error is technically imprecise; an exception isn't
>*necessarily* an error.)
>
True, but in this situation, if you are going to modify code by
wrapping with try-except to catch integer divisions, you might as
well fix the code? OTOH, if you wanted a facility to make existing
code run the way you want, maybe a divHook could be put somewhere
so you could define a temporary div with assertions about the
arguments, and logging of anomalies, etc., or whatever you needed,
in a single tweak.

>>>   from __future__ import float_division
>>>   from __future__ import real_division
>>>   from __future__ import new_division
>>>   from __future__ import division
>>
>>'float_division'.  There's no type corresponding to "real", nor is
>>that terminology used anywhere in the docs; 'new_division' and
>>'division' strike me as unclear.
>
>Ditto.
Agree on the last two, but if there's a better real type than float
coming in the future, '/' would presumably produce it as a result.
In that case real_division would anticipatorily make sense, ISTM.

I can live with div(x,y) and if so, mod(x,y) does seem to make
for symmetry. 

BTW, will '%' as an integer op go away too, by symmetry?