Language change and code breaks
Peter Hansen
peter at engcorp.com
Sat Jul 14 11:59:20 EDT 2001
More information about the Python-list mailing list
Sat Jul 14 11:59:20 EDT 2001
- Previous message (by thread): Language change and code breaks
- Next message (by thread): Language change and code breaks
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): Language change and code breaks
- Next message (by thread): Language change and code breaks
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list