Language change and code breaks

[Peter Hansen]

Guido van Rossum wrote:
> 
> Peter Hansen <peter at engcorp.com> writes (after much good stuff about
> transitioning):
> 
> > 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.
> 
> Well, I don't know about you, but *I* am reluctant to say "screw you"
> to all those people who depend on Python script written by
> professional programmers who no longer work there.

"Screw you" might have been a little strong.  (And for those just
joining, I _am_ one of those professional programmers about which
I was making the suggestion...)

Nevertheless, I want to make the clear point (if I haven't already)
that I'm not suggesting screwing every such programmer... just 
those who are actively using code which would be broken, who will 
not take the time (however small we might make it) to modify the 
source, and yet who "must" have their code work under the new Python.

Are there really any people like that?  Enough to make it
a key factor?  I'm not sure I can even think of any realistic
cases where anyone like that exists (he said, trolling for
someone to point out an obvious example or two).

I thought all the rpm stuff from RedHat might be an example.  But
it runs with its own 1.5.2 installation, as far as I can tell.
No obvious problem there.

There are all those users (presumably) who are using Python code
somewhere but don't even realize it.  They most likely aren't going
to be the sort to upgrade their installation any time soon, so their
environment is secure.

There are us types using Python in commercial/industrial 
environments.  Probably we suffer the biggest impact for
several reasons, and yet we are also in the best position to
cope with the damage (most resources, typically much newer
to Python than the scientific community, probably actively 
maintaining our code already, most likely aware of this issue
and maybe directly involved).

There's the lot of us active in c.l.p, but we know about the 
change, have access to the tools, have participated in the
preparation phase, and have taken the time to be ready before
the change even hits (that is, before the _end_ of the transition
period during which code breakage doesn't happen).

What other classes of users have I missed?  One of the first
steps in requirements engineering is to identify use cases, 
which requires understanding the various user roles involved.
Let's just finish defining the types of users, analyze each
one in terms of risk (probability of impact, extent of impact,
quantity of users involved), possible mitigating steps (warnings,
tools, etc.), and perhaps contingency plans.

> I also don't want to fork the code base.  There are *still* folks
> using Perl4 scripts who can't upgrade.  I don't want to do that to the
> community.

Maybe this can be a practical example of how much more maintainable
Python code is than Perl code.  I can't imagine anyone suggesting
that people using Perl scripts should go through all their source
(or someone else's) and change it to make it compatible with the
latest Perl.  I actually *can* imagine suggesting that seriously
in the case of Python code.  (Forget imagination, I *am* suggesting
it!)

> So indeed, we'll need to be *very* careful with this kind of
> transition, providing tools, warnings, anything we can think of.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

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