Make it a major version number change (was Re: PEP0238 lament)

[Peter Hansen]

Bjorn Pettersen wrote:
> 
> > From: Guido van Rossum [mailto:guido at python.org]
> [snip]
> >
> > (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.)
> 
> Thanks for taking the time to address these issues. I agree your
> proposed three steps would go a long way towards easing any
> compatibility concerns. I have one request though... make the first
> release where the new division is the default be named 3.0. It's much
> easier to go to management and say "There's a new stable major release
> of Python that I think we should go to, but since it's a major release
> I'll need to spend some time testing our current applications."
> Management tends to be much less willing to schedule maintenance time
> every six months for what they consider minor point releases.

Hear hear!

I hate the thought of the work required to scan/fix/debug 
already working code, but if this has to happen, and can't
be made to work without breaking existing code (e.g. by 
introducing *two* new operators), then at least follow
the convention we apparently all believe exists and 
make this a *major version number change*.

(But two years until the change really becomes the default
would at least be an improvement over the truly scary 
apparent speed implied by the sudden posting of a patch.)

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com