caller was compensating for this, others weren't, easier to fix the
routine than its callers (it's unexpected that an error return may
require the caller to decref an output argument).  Noted but did not
yet fix what looks to be a subtle algorithmic problem that can result
in a bad answer in an unlikely (but possible) case.

Do not encode the file position in the transaction id used for undo.
An attacker could construct a pickle with a bogus transaction record
in its binary data, deduce the position of the pickle in the file from
the undo log, then submit an undo with a bogus file position that
caused the pickle to get written as a regular data record.  Bad stuff.

The new implementation uses a straight linear search backwards from
the most recent transaction header.

directly without doing the unghostification dance.  Repaired to cache
the child length once in a local vrbl, bracketed by the right
persistence stuff.

an error return.

error return let a newly allocated object leak; curiously, there was
one more of these in the Zope3 version of the code than on the trunk.

If MUCH_RING_CHECKING is not defined (the default), then:
  - use a macro for OBJECT_FROM_RING() instead of a function call, and
  - define IS_RING_CORRUPT() to be constant 0.

XXX Sometime before Zope 2.6 final we should probably remove the
MUCH_RING_CHECKING and ENGINE_NOISE code entirely.

finish the persistence dance.

code and slashed nesting depth, but no semantic changes yet.

In the TRACE_REFS version of the code, call _Py_NewReference() instead
of INCREF to bump the refcount from zero to one.

When exiting the function, don't DECREF the object back to zero
refcount, as that will reinvoke the object's deallocation function.
XXX Why did this ever work?

and Zope3 branch versions of this function.  No semantic change.

to figure out to fix the off-by-1 bug in BTreeItems_slice().

"next" functions, these can return a PER_USE() error *after* decrefing
the keys and values left over from the last call.  But they don't mark
the iteration as terminated, so finiSetIteration() will also try to
decref the leftovers.  The fix is to mark the iteration as terminated
when these functions fail.

"BTreeItems slice contains 1 too many elements"
This also fixes many related glitches, such as that giving an
out-of-bound slice index raised IndexError instead of clipping.

BTreeItems_slice():  Emulate Python slicing semantics in all cases.

testBTrees.py:  new testSlicing() tests in MappingBase and NormalSetTests
to ensure that slicing of .keys()/.items()/.values() works exactly the
same way as slicing of Python lists, in all one-sided, two-sided and
whole-structure ([:]) cases, with both negative and positive slice indices,
and mixtures of + and -, and whether in bounds or out of bounds.

+ Documented the arguments.
+ Used BUCKET_SEARCH.
+ Vastly reduced nesting.
+ Changed the "*changed" argument to get set true whenever PER_CHANGED
  is called, i.e. whenever the bucket mutates.  The purpose of *changed
  wasn't documented, and its only use was in the BTree set routine, which
  is known to have at least one bug.  So it wasn't clear what the purpose
  of *changed was.  What it did do is get set true if and only if the
  key was found in the bucket and its value was replaced, and I couldn't
  imagine a plausible reason for why the BTree set routine could care
  about that alone (all other calls to _bucket_set pass NULL, so there
  were no other clues).
+ Fixed all places where error returns didn't finish the persistence
  dance.

micro-optimized BUCKET_SEARCH macro.  Change _bucket_get() to use
it (more later).

way out of date (prints stuff and asserts instead of raising unittest
failures).

does.

iteration protocol a destructor (finiSetIteration()), to plug assorted
leaks of keys, values and even BTree nodes.

modifications were needed in Zope (only two files). A lot of unused
(or rarely) features were removed from the Interface package. Slightly
deeper imports are needed.

initSetIteration(), because it specifically doesn't want to bother
getting values out of mappings.

Elsewhere, repaired all other known cases where uses of the
TEST_KEY_OR_SET macro did early exits without finishing persistence
dances (Jeremy confirmed that's a Bad Thing -- creates unghostifiable
cache hogs).

a persistence dance on the buckets/sets it handles directly by itself.
If so, a similar but different change is also needed on the Zope3 branch.

SetIteration structs.