and started repairing obvious errors in their docs.  More to come.

supplied by the correct BTree modules.

the algorithm in a way I believe Jim suggested a few weeks ago (but that
I didn't understand then).

reason for it not being enabled before.

Workaround for bug in Python versions upto and including 2.1.3.  If
the interpreter was builtin without large file support but the
platform had it, os.path.exists() would return false for large files.
The fix is to try to open the file first, and decide whether to create
a new file based on errno.

(Only the two of the last three chunks of the diff affect this
behavior.)

Also cleanup imports and add some whitespace between arguments to func
calls.

one bucket.

returning X, contradicting the docs and common sense.
difference(None, X) continues to return None.

Noted that the way difference() treats None doesn't match the docs and is
almost certainly wrong.

nextBTreeItems() and nextTreeSetItems():  ditto.

the recursion (iteration is quite natural here -- it was tail-recursive).

self, which effectively turned the error into a fatal error.  Fixed.

code, are bogus when PERSISTENCE is #define'd.  Repair them.

a BTree is empty if and only if its firstbucket pointer is
NULL, so there's no need to keep checking nonzero inside the
loop.  Also, the pointers here are all local, so there's no
need to incref and decref them -- the apparent necessity was
just an artifact of using the bucket assignment macros.  So
stopped using those macros, and the need for incref/decref
operations went away too.

PyVar_AssignB(), ASSIGNB(), ASSIGNBC():  Turned out these
are no longer used anywhere anymore, so removed them.

PER_UNUSE():  New macro to capture the endlessly repeated
PER_ALLOW_DEACTIVATION + PER_ACCESSED pair.  As the comment
says, so sue me <wink>.

Bucket_deleteNextBucket():  Documented & simplified.

of verifying that BTree invariants are satisfied, raising AssertionError
if they're not.  Nothing calls this method by magic; it's for debugging.

some of this code is needed, and to help track down an odd bug Guido is
seeing.  assert()s won't trigger except in a debug build.

The old ZEO test suite does not accept description as a keyword arg.
Luckily the description is only there to help debug problems; it isn't
required for successful completion of the test.

PyMalloc(), PyRealloc():  Call malloc() and realloc() directly instead
of PyMem_Malloc() and PyMem_Realloc().  If the latter are used, then
memory must be freed via PyMem_Free(), but PyMem_Free() isn't called
anywhere -- memory is released via raw system free().  It would probably
be better to change all uses of free() instead, but that's A Project (well,
compared to this ...).

is now almost as simple as it's been trying to be <wink>.

mean any of no error, an expected index error, or an unexpected error;
naturally, callers conflated those.  The return value now distinguishes
among the cases.

BTreeItems_seek():  Use the new form of PreviousBucket().

purpose wasn't clear, and the few places that bothered to call them seemed
to be trying to cater to empty buckets.  But empty buckets aren't legitimate
in a BTree (or, if they are, lots of BTree code is broken).

BTreeItems struct:  finished figuring out what's in this, and documented it.

BTreeItems_seek():  rewrote and simplified, to avoid use of the now-
removed XYZBucketOffset() functions.  Repaired places where bucket access
time wasn't getting updated.  There are still insecurities in its use of
PreviousBucket() (for another day).

BTreeItems_slice():  now that I know what it is <wink>, create an empty
slice in the intended way.

NewBTreeItems():  documented its calling sequence, and added code to
protect against a NULL highbucket argument.

BTree_maxminKey():  no longer calls the XYZBucketOffset() functions.

a BTree in an invalid state.  Normally, _BTree_set() repairs this before
return, but in case of error may not.  Now it does.

an error return leaked references.

a BTree in an invalid state when called with an empty BTree.  I still
need to change callers to ensure that the BTree is never left in that
invalid state (it can be now).

between the Zope2 and Zope3 versions.

deletion endcases uncovered by the new degenerate-BTree tests.  The
degenerate testDeletes() and testEmptyFirstBucketReportedByGuido() are
enabled now.

disabled for now, because it dies in lots of ways.  I hope, but don't know,
that they're all related to "Guido's bug".

Also backported the "Guido's bug" test case from the Zope3 project.  This
is also disabled for now.

changed() in cPersistence.c now calls the jar's register() method.
Connection's register() method just calls get_transaction().register().

This redirection would allow specialized Connection's to change the
default policy on how the transaction manager is selected without
hacking the Transaction module.

The cPersistence.c code is based on _PyPersist_RegisterDataManager()
from the Zope3 code.

XXX Should start still do path munging?

search returned a seemingly random slice of the tree.  A new test on the
painfully constructed highly-degenerate BTree turned up lots of these.
It turns out that BTree_rangeSearch had a much harder job than it
thought it had <0.7 wink>.

for lo > hi either, except if they happened to be in the same bucket.  All
sorts of strange results followed (the range should be empty if lo > hi,
and is after this patch).