Eliminating upgrade risk

[Donn Cave]

Quoth "James C. Ahlstrom" <jim at interet.com>:
[... re research language priorities ]

| I am afraid I have to agree with Robin here.  My company "solved"
| this problem by staying with Python 1.5.2.  I do plan to upgrade when
| I have the time, but absent any tools to at least flag incompatibilities
| this may never happen.
|
| My new Red Hat 7.1 system reports that its Python version is 1.5.2.
| Apparently I am not alone.  I believe many Python users are at 1.5.2.

We're up to 2.0 here, but you got me thinking about it and I checked -
we still have 1.5.2 installed on at least one host, if I need to verify
that something actually works on 1.5.2.  Hope folks will do that when
possible.  I do like some things about 2.0, but 1.5.2 has what you need
to write a working program if you don't want to introduce gratuitous
incompatibilities with the Red Hat et al. base.  Even those who plan
to keep up with Python's evolution have a stake in its reputation as
a useful programming environment, and eventually it's up to us.

	Donn Cave, donn at u.washington.edu

PS  I used a C++ class binding technique per your report in a long ago
    workshop, http://www.python.org/workshops/1995-12/papers/ahlstrom1.html,
    for the BeOS native C++ API, and it has worked out OK.  The details
    are somewhat different by now (not necessarily for the better - my
    class hierarchy module division still needs some work!) but it does
    what it needs to with those user-defined virtual functions.  Thanks!