Eliminating upgrade risk

[Steve Holden]

"James C. Ahlstrom" <jim at interet.com> wrote in message
news:3B601811.4B68578B at interet.com...
>
> Robin Becker wrote:
>
[ ... ]
> The problem is that the new Python features, as wonderful as they are,
> are chosen for Computer Science Purity, not day-to-working-day
> importance to someone actually trying to write a widely used bullet
> proof program.  The current rate of language change is fine for a
> student or casual programmer I'm sure, but I don't have that luxury.
>
I prefer to think that the problem here is that the new Python features that
would break existing code are to fix a wart that has been in the language
for a long time. Originally my own approach was "so live with the wart", but
I really don't anticipate the division change giving me many problems in my
own (admittedly limited) installed base.

The rate of language change has little to do with it, and the main question
is "does code from the last version run on the new version?"

How many cases (besides the division proposal, for which the timeframe is
two years, or indefinitely if you use the command-line option) can you quote
where that question would be answered in the negative?

new-features-don't-stop-old-features-working-(mostly)-ly y'rs  - steve
--
http://www.holdenweb.com/