[Jim Abramson]
I definitely understand your point and knowing about these issues is certainly useful. Maybe mentioning the unit tests muddied my original question.
My practical reality is a production environment in which a number of applications are already in heavy use, running happily against python2.3.2. I want to run an up-to-date Zope2 that can talk to these applications (i.e. as a frontend utility), without the considerable block of setting up a whole new python build and upsetting the otherwise-placid state of affairs.
You can do that, but then you're on your own for support. Zope Corp sometimes pays me to track down and fix Python bugs that affect Zope, but they're not going to pay me to track them down a second time.
What's confusing, though not exactly critical, is why source distributions seem to allow for some leeway as far as which python version you build Zope onto, but binaries have this less forgiving posture. The less-forgiving approach implies that Zope will not work with an earlier py version, but that doesn't exactly seem to be the case (it works, just 'sub-optimally').
After you experience a segfault under heavy load, I doubt you'll be posting a message here titled Help with sub-optimal memory behavior? <wink>. Most Zope users on WIndows don't even have C compilers, so Zope on WIndows ships with precompiled binaries for everything Zope needs, including Python. So it goes. You can build Zope from source on Windows too if you want to, although it's an undertaking. Note that the Zope 2.7.2 info page: http://zope.org/Products/Zope/2.7.2/Zope-2_7_2-released lists Python 2.3.3 as the minimum supported version. That at least means nobody at Zope Corp will pay attention if you try to report a bug against Zope using an earlier version. Zope 2.8 will require 2.3.4 minimum (because of the Zope-critical bugs still in 2.3.3 I listed last time, which affect code Zope 2.8 inherits from the Zope 3 project).