[Zope] Zope2.7.2 with ActivePython2.3.2

[Jim Abramson]

Thanks Tim,

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.  

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').

Jim

-----Original Message-----
From: Tim Peters [mailto:tim.peters at gmail.com] 
Sent: Tuesday, August 24, 2004 5:05 PM
To: Jim Abramson
Cc: zope at zope.org
Subject: Re: [Zope] Zope2.7.2 with ActivePython2.3.2

[Jim Abramson]
> As a small aside to this topic, I just ran the (entire?) suite of unit

> tests - 2586 of them - with Zope2.7.2 using an ActivePython2.3.2 
> binary install (pretty much out of the box) on WinXP.  I realize this 
> isn't everything as far as a full compatibility assessment goes - but 
> nothing erred.

Bugfix releases of Python strive not to change visible behavior, so
that's not surprising.  Later versions of Python are generally required
because of bugs in Python that afffected Zope, often in endcases so
bizarre (Zope plays in Python's dark corners like few other apps dare)
that only one way to trigger it is ever discovered. 
Tests to ensure that such bugs are fixed end up in Python's test suite,
not in Zope's -- because they're Python bugs, not Zope bugs.

For example, here are a subset of items fixed in Python 2.3.3 that were
discovered in Zope (2 or 3):

- Critical bugfix, for SF bug 839548:  if a weakref with a callback,
  its callback, and its weakly referenced object, all became part of
  cyclic garbage during a single run of garbage collection, the order
  in which they were torn down was unpredictable.  It was possible for
  the callback to see partially-torn-down objects, leading to immediate
  segfaults, or, if the callback resurrected garbage objects, to
  resurrect insane objects that caused segfaults (or other surprises)
  later.  In one sense this wasn't surprising, because Python's cyclic
gc
  had no knowledge of Python's weakref objects.  It does now.  When
  weakrefs with callbacks become part of cyclic garbage now, those
  weakrefs are cleared first.  The callbacks don't trigger then,
  preventing the problems.  If you need callbacks to trigger, then just
  as when cyclic gc is not involved, you need to write your code so
  that weakref objects outlive the objects they weakly reference.

- Critical bugfix, for SF bug 840829:  if cyclic garbage collection
  happened to occur during a weakref callback for a new-style class
  instance, subtle memory corruption could result (in a release build;
  in a debug build, a segfault occurred reliably very soon after).
  This has been repaired.

- At Python shutdown time (Py_Finalize()), 2.3 called cyclic garbage
  collection twice, both before and after tearing down modules.  The
  call after tearing down modules has been disabled, because too much
  of Python has been torn down then for __del__ methods and weakref
  callbacks to execute sanely.  The most common symptom was a sequence
  of uninformative messages on stderr when Python shut down, produced
  by threads trying to raise exceptions, but unable to report the nature
  of their problems because too much of the sys module had already been
  destroyed.

There are more in 2.3.4:

- Fixed problem where PyWeakref_NewRef() and PyWeakref_NewProxy()
  assumed that initial existing entries in an object's weakref list
  would not be removed while allocating a new weakref object.  Since
  GC could be invoked at that time, however, that assumption was
  invalid.  In a truly obscure case of GC being triggered during
  creation for a new weakref object for an referent which already
  has a weakref without a callback which is only referenced from
  cyclic trash, a memory error can occur.  This consistently created a
  segfault in a debug build, but provided less predictable behavior in
  a release build.

- Fixed a bug in object.__reduce_ex__ when using protocol 2.  Failure
  to clear the error when attempts to get the __getstate__ attribute
  fail caused intermittent errors and odd behavior.

You're insane if you think you want to track down one of those
nightmares yourself all over again <wink>.