Language change and code breaks

[Peter Hansen]

Guido van Rossum wrote:
> 
> Peter Hansen <peter at engcorp.com> writes:
> > I can't see a simple answer to this.  It looks as though there
> > are two camps, to both of whom it is absolutely essential that
> > Python act in a specific way.  And the two ways are completely
> > incompatible.
> 
> No, that's not it.
> 
> The problem is that you have written much more Python code than the
> chemists of the world, and if I were to change the language, you would
> have to go through all that code to find out which slashes to replace
> with 'div'.

Therein (perhaps) lies the sign for which path to take.

*I* would only have to make that change to code which I wanted
and needed to support under newer versions of Python.

Many programs would not need changing at all, as they would 
just continue to run under older versions of Python.  (Zope could
be frozen in time, capable of running only under Python 1.5.2,
were it not maintained.)

Maintained code can relatively easily be refactored to deal
with the new situation.  This isn't rocket science, and 
automated solutions that handle 95% of the cases could likely
be written.  (If many people are concerned about the 
potential code breakage, there must therefore be many 
ready-made test cases for such a utility in the form of
their jeopardized code.)

Large, complex applications -- those for which the scan 
would most likely miss some cases -- should have
sizable regression test suites which surely will catch
the remaining problems.  If someone has such a program and
insists it "must" run under the newer Python, but does
not have a test suite, are you really going to try to keep
that person happy too?

> > Doesn't that mean that the only solution that can be accepted
> > without causing serious complications is to make the change,
> > but clearly support a command line option (or some other
> > configuration setting) to enable the current behaviour,
> > so those who have depended on integer division can continue
> > to run old code under the new engine without fear of
> > breakage?
> 
> This has been said many times in other contexts: command line options
> to change a particular behavior are evil.  It would mean that library
> modules could't depend on either behavior.
> 
> If we're going to give users a choice, it's going to be some kind of
> per-module switch.

So in the transition period, a per-module switch is available. It
can be enabled globally in some way to apply either to old code 
which knows nothing about this but which hasn't been fixed to account
for the change, or to new code which might require the new
behaviour.  Make the new behaviour the (global) default, which is 
something we "professional programmers" can live with provided we 
have a convenient way (site.py, environment, what-have-you) of
disabling it for programs we know won't work or in environments
where we haven't had the time to do the full transition.

After the transition period, screw the professional programmers 
who won't take the time to modify their existing code and yet 
who selfishly insist that their wonderful program *must* be
allowed to continue running under the new Python without 
problem.

I don't think this truly covers all the cases, but we have 
to draw the line somewhere.  Maybe before the gavel drops
on this one, we can develop the proposed "div-scan" utility
and test it out for those of us most concerned.  After it
has been proven in the field, we go ahead and break things
and take our lumps for a while.  Things settle down, the
problem fades into history, and c.l.p swarms with happy 
newbies. :-)

> > Anyway, that's not my problem. :-)
> 
> Yes it is!  Unless we find a solution that *works* you will be
> affected.

Well, quite true.  If I'd been thinking better, I might have
said "this is not really a problem in my particular case, 
because my code base is small enough and we are new enough 
to Python that we can bite the bullet and scan/fix all 
several hundred modules we have written.  Not the end of the
world for me, but not exactly nice to rub it in anyone else's 
face.  Apologies.

As you said, we are professional programmers: we have to do this
kind of thing all the time in other environments, especially
to deal with API changes by the large-evil-software-manufacturing 
empire-which-must-not-be-named.  We regularly upgrade 
C compilers for embedded systems, for example, in a never-ending
and usually unsuccessful attempt to get away from the bugs 
of one version but we always encounter new bugs and have 
code breakage etc. as a result.  We live with it.  If it really 
bothered us, we wouldn't upgrade.  Same solution works here.

It really isn't the end of the world, and I think many of us, 
(I'm sure I don't speak for all, however) can agree with the 
basic premise ("least astonishment") that the current behaviour
is overly surprising to newcomers, etc., therefore likely to 
dilute the potential user base, etc., and therefore overall a
negative thing to the strength of the Python movement,
and therefore likely over the long term to negatively impact 
the value of Python to us.

(Those who disagree with that would perhaps need to explain
why, if they aren't really interested in the benefits that
continued expansion of the Python user base brings to the table,
they however insist they cannot just freeze their environment
with the current version of Python and therefore not be
affected by this change in any way.  If you *have* to upgrade
but you *won't* maintain your code, maybe you're just being 
selfish.  (Flame bait, but controversial statements
can bring out some worthwhile points of view... :)

> > So, O' BDFL, why not take the most Pythonic approach
> > and use a solution which *pragmatically* achieves a good
> > practical balance but which causes purists always to feel
> > a little uneasy and which can lead to perpetual discussion
> > about "warts" and why other languages are better and.... ;)
> 
> Believe me, I'm trying.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Clearly you are trying, hard.  And believe me, we appreciate it
immensely.  I'm trying too... :)

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