Comment on PEP-0238

Robert J. Harrison rjh at 3-cities.com
Sat Jul 7 19:05:44 CEST 2001


Guido van Rossum <guido at python.org> wrote in message news:<cpsngaja4g.fsf at cj20424-a.reston1.va.home.com>...

> The warning framework and the future statement are there to make the
> transition easier.  Here's my plan, "new division in four phases":
> 
> 1. First we introduce a new function div() and a future statement that
>    makes integer division return a float result for a specific module.
> 
> 2. In a following revision, we add a warning when / is used on two int
>    or long arguments, recommending to use div() instead.  (It is
>    important not to start warning in phase 1, so folks have time to
>    switch to div() voluntarily first; maybe phase 1 could have a
>    command line option to warn about integer division.)
> 
> 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.
> 
> 4. Finally we can implement the "future" behavior by default.
> 
> I haven't picked dates yet; if folks agree, I would like to add div()
> and a future statement to 2.2 and space the other steps a single
> revision apart, so phase 4 would be at Python 2.5 (April 2003, if we
> keep the current release schedule up).  Is that too aggressive?
> 
> I currently favor div(x, y) over x//y and x div y.  Maybe also add
> mod(x, y) for symmetry (that would also explain divmod() as a
> messenger from the future :-).
> 
> I'm not sure how to spell the future statement.  Here are some
> choices:
> 
>   from __future__ import float_division
>   from __future__ import real_division
>   from __future__ import new_division
>   from __future__ import division
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)


Sounds good to me.  If it must happen, then the sooner the better.

However, I think that some details of the numerics also need to
be clarified before you boldly go.  Specifically,

 - What about long division?  A float cannot capture all results.
   Should it raise a Value/Range error?
   Should the programmer be forced to use divmod?
   Should it return a rational?  
   I don't really like the last two choices and the first two choices
   obviate much of the usefulness of longs.

   Perhaps Paul Dubois's kinds mechanism comes to the rescue?
   He does have a trial implementation in numeric (though 
   I am not in favor of seeing much of the current numeric 
   integrated into the core)

Robert

rjh at 3-cities.com



More information about the Python-list mailing list