Eliminating upgrade risk

[James C. Ahlstrom]

John Roth wrote:

> That last sentence is what is scarey, not PEP238 or any of the
> other specific proposals. There's an endemic mindset in the xNIX
> community that simply doesn't understand the risk aversive behavior
> of many of the large shops. If compatability isn't guaranteed, then
> an upgrade is a project - which has to be scoped, justified, planned,
> and then prioritized with all the rest of the projects.

This attitude is so pervasive in commercial shops it even has a
name "FUD".  And yes, I run a commercial shop and I have
Fear Uncertainty and Doubt about anything I don't have time to
research.  In other words, most everything.  A rapidly evolving
Python absent a conversion scanner tool is a major problem.  I
don't think I know John, but obviously he must own a major
flame suit to make this point in a Unix-geek group.

I am not saying (nor is anyone else AFAIK) that Python should
not evolve, maybe even rapidly.  My son (16 years) wants to learn
programming, and his school wants to teach him Pascal.  Yuk!
Much better to learn Python, but how to explain my pet peeve
08 is an illegal integer?

My point is that no one expects Python's evolution to be
controlled by the needs of commercial users.

But it would be naive to ignore the problem that Red Hat has
declined to upgrade from 1.5.2.  A quick
find | wc shows that Red Hat 7.1 has 84,494 lines of Python
code not counting the Python libraries.  I don't know how
Red Hat is supposed to upgrade Python and still know their
code works.

BTW, it's not just the division proposal.  The change from
lst.append(x, y) to lst.append((x, y)) is another example.

Jim Ahlstrom