PEP0238 lament

[Guido van Rossum]

> Jim Abrams wrote:
> 
> > Because every camel has its straw, I need to agree here. I, and most
> > of my python buddies, fight with bloodstained teeth and nails to get
> > python in our projects and developments. I can't see winning too many
> > arguments when my opposition can pull out 'the division operator' to
> > shoot me down. I can't see budgeting time and people to making sure
> > the division operator works after an upgrade. I'd be laughed into data
> > entry ;).

Erik Max Francis <max at alcyone.com> writes:

> Indeed.  If this is implemented, it will be a black eye for Python.  Any
> anti-Python advocate will be able to point at this and say, "Look,
> that's why you shouldn't switch to Python.  The semantics of the builtin
> operators changes from release to release."  Problem is, they will be
> absolutely right.

This seems to be the crux of the anti-PEP-238 sentiments, and I want
to take it very, very seriously -- without losing the PEP.

If you agree that, if it weren't for breaking old code, PEP-238 would
make Python a better language, what can we do about that old code?

I propose the following measures.  Let's discuss whether these are
conservative enough, from the perspective of someone who has a large
body of old working Python code.  (From the perspective of someone who
wants int division for other reasons, these can never be conservative
enough. :-)

(1) A very long wait period before the new division becomes the
    default.  The PPE mentions at least two years; we can go over
    that.  Python 2.2 will introduce the first release where it's
    *possible* to write "from __future__ import division"; we'll have
    to wait until 1.5.2 is only a faint memory (like 1.4 is now) and
    2.2 pretty old.  (The current release pace is two revisions per
    year, so two years would make 2.6 the first release where new
    division is the default.)

(2) A command line option to change division semantics.  I propose
    -Dnew to make the new division semantics the default, -Dold to
    make the old semantics the default.  -Dold will be the default
    until the wait period is over, then -Dnew will become the
    default.  The -D option is retired when nobody needs -Dold any
    more.  Modules that contain a future statement always use the new
    default; there's no way to force the old default on a *per-module*
    basis (since that would be a language feature that could never be
    removed).

(3) As of 2.2, all the standard library code should work regardless of
    the -D option.  That is, all library modules (and modules in Demo
    and Tools) should use // whenever int division is required, and
    should use the future statement whenever float division is
    required.  This is necessary so that use of the -D command line
    option doesn't break the standard library.

Anything else?

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