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
> 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)
rjh at 3-cities.com
More information about the Python-list