Comment on PEP-0238

[Steve Holden]

"Guido van Rossum" <guido at python.org> wrote ...
>
> 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.
>
This seems a reasonable approach.

> 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?
>
If you're going to do it, you might as well make a start. Almost two years
before something breaks should be good enough for most organizations.

> 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 :-).
>
That seems sensible.

> 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/)

from __future__ import unified_field_theory
from __future__ import unified_division

regards
 Steve
--
http://www.holdenweb.com/