PEP0238 lament

[Guido van Rossum]

"Bjorn Pettersen" <BPettersen at NAREX.com> writes:

> 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.
> 
> If there was to be a scheduled 3.0 release, any other source
> incompatible changes that were seen as important would also have a
> natural place to go.

Thanks for the suggestion.  I think I'll do it this way: Python 3.x
will be the first incompatible version, Python 2.x will require
__future__ statements or other explicit ways to indicate that the
programmer wants the new feature.

For less disturbing changes like nested scopes or generators (which
would break only very small amounts of old code), we can introduce the
new feature for real in the next release (e.g., nested scopes will be
standard in 2.2, I expect generators will become standard in 2.3), but
for devastatingly code-breaking changes like division, I'll wait until
3.0 before it becomes the law.

A number of people have proposed version directives or directives to
select specific division semantics.  I am not in favor of this kind of
solution, since it makes the two alternative semantics a *permanent*
wart of the language.

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