PEP0238 lament

[Barry A. Warsaw]

>>>>> "DB" == David Bolen <db3l at fitlinxx.com> writes:

    DB> Thus, the very fact that the behavior is moving towards
    DB> breakage may hold up people from moving for fear of the
    DB> resource involved to ensure they don't have a problem, which
    DB> in turn may prolong the period of time when such breakage is a
    DB> risk.

If this is a real fear then you can never upgrade your Python, even if
a new version introduces no language changes.

A new version will always have /some/ changes, even if it's only
patches to the library, or improved performance.  Otherwise there'd be
almost no reason to release a new version of Python, and we can all
just go home.  The "Python-is-perfect-now" crowd would be happy, but
they'd be just as happy to unsubscribe from this newsgroup, ignore any
future Python development, and stick with 1.5.2 forever.

Now, you may have a mission critical application that still might
break on an upgrade to such a hypothetical new version.  Maybe it's
because one of your modules has a subtle race condition that behaves
different suddenly because you just upgraded to the newer faster
Python.  Or maybe it's relying on an undocumented feature that got
removed because it was buggy (and undocumented).  Or maybe one of your
extension modules isn't quite thread-safe and breaks when Python
eliminates its global interpreter lock.  Whatever.

But if this is really a fear then upgrading Python might not even be
your biggest worry.  What if you upgrade some underlying library, or
apply an OS patch, or add more memory, or a faster disk, or change to
a new C compiler?  Any or all of those things may break your code or
it may not.  I've certainly been victim to such "innocent" upgrade
breakages.  So you still have to think hard about it, test
aggressively, plan defensively, and cross your fingers.  Why would you
upgrade Python any differently?
    
    DB> I'm still at 1.5.2 and unlikely to move beyond that until at
    DB> least this year's end.  At that point I would have been using
    DB> Python 1.5.2 for about 21 months with it fully deployed in all
    DB> production sites around 18.  I would anticipate about a 6
    DB> month preparation cycle before moving to any new release (code
    DB> test, ensure third party support, etc...) and would then
    DB> expect to get at least 12-18 months run time again.  Right now
    DB> I was planning on moving to 2.1.1 unless 2.2 looked to arrive
    DB> soon enough (unlikely) to meet the testing/third party
    DB> criteria.

Sounds like a reasonable plan.

I think the only thing you can do is try to get assurances that your
mission critical applications are compatible with newer versions of
Python.  If you can't get such assurances from the vendors, or you've
got a lot of third party code, then you can test and fix stuff
yourself.  Or run multiple versions of Python and migrate your
applications one by one.  Or never upgrade.  There's no law saying you
should.

But there's also no reason why Python should stagnate, or not fix its
warts, or not evolve, so that /new/ applications or newer versions of
existing applications cannot be written more elegantly, more
succintly, or more maintainably.  No, new versions should not
gratuitously break old code without some systematic migration plan,
but that's what __future__ and the PEPs are all about.

-Barry