PEP0238 lament

[Guido van Rossum]

David Bolen <db3l at fitlinxx.com> writes:

> Could we also at least keep in the fray a slightly alternate question
> of "what can we do about the PEP"?  I mean, as has been suggested
> elsewhere at times, one solution to the old code is not to break it -
> using "//" (or some other sequence) as the float division is backwards
> compatible (no current code using it) and can be introduced at any
> time for new code to use.  It wouldn't even need a lengthy period, but
> could show up right in 2.2.

No, this does not solve the problem.  The / operator overloads two
different operations and breaks an (IMO) important rule about math
expressions.

> It seems to me that the only real argument against that is aesthetics,
> or am I missing something?  Of course I'll play a little devil's
> advocate and say that I probably agree with the aesthetic argument, but
> only to the point where it breaks down against my concern for the
> compatibility argument.

I don't see it as just aesthetics.  It's like the alleged bug that
caused a figter jet to flip over when crossing the equator, a subtle
bug waiting to happen.

[...]
> What happens when you reach the release where the __future__ is no
> longer needed?  Will that stay in the standard library for some period
> of time after that anyway (or else the -D command line option might
> cause breakage in the standard library)?

As long as the -D option can change the defaults, all library code
needs to keep the __future__ division statement.

> > Anything else?
> 
> Just one thought on the warnings defined in the PEP (which in any list
> like the above, I'd probably suggest highlighting as a point).
> They're not perfect since there are plenty of environments where they
> might not show up, but if I read correctly, as of 2.3 any integer
> divisions that lose data will generate a warning, but only until the
> new behavior becomes default.

I just decided that the new behavior won't become the default before
Python 3.0.

> Unlike many (all?) of the prior backwards-incompatible features, which
> first warn about breaking behavior and then fully break behavior, but
> continue to do so visibly (e.g., "yield" remains a keyword), this one
> ends up in a state where the break goes from being warned about to
> being silent and no longer visible.  That might be part of my gut
> concern about compatibility, as it makes me feel that there is a
> window of opportunity to catch the problem, but if you miss it,
> discovering dependencies on old behavior becomes very problematic.

Actually, nested scopes shares this property.  It's just that code
affected adversely by nested scopes is pretty rare.

> Could there be a way to continue to request the activation of the
> warning noted in the PEP even after it has been turned off by default
> and the behavior has officially changed?

Yes, but this would have to be combined with setting the default
back.  You can't warn about the old behavior and implement the new
behavior at the same time: that would be the worst of both worlds.

> Doing a static analysis of
> modules to find uses of division can help inspect older modules but
> having runtime warnings may prove helpful when trying to make use of
> an older module in a few years with a current Python.  This sort of
> thing might even be helpful as a general recommendation for other
> backwards-incompatible changes that by their nature become silent once
> fully enabled.

An easy solution of course is to keep an older version of Python
around and see if the code triggers any warnings with that version.

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