On Jul 13, 2005, at 7:32 PM, Peter Fein wrote:

> IIRC, I asked about this a few months back... Devs seemed opposed,
> don't
> remember why. The way I dealt with this was to subclass BTree and
> extend
> the methods that modify size to keep track of the length in __len.
> I'll
> look in to posting that code.  Can't think of a good reason not to do
> this - it's been working fine for me.

I had some more time to think about this and I'm remembering why things
are as they are with BTree.  The problem I expressed earlier is that
this
would represent a duplication of information, and there would be a
continual
risk that the cached size would be wrong.

Even worse, though, a size attribute, stored on the BTree or some other
Persistent instance, would be changed every time any key in the mapping
is changed.  That means the Persistent instance holding the size would
be accessed and invalidated frequently, and this would tend to increase
the frequency of ConflictErrors.

By the way, because of the way Persistent Instances work, calculating
the size
by iterating over the tree only causes the actual loading of the
BNodes of the
BTree (a logarithmic function of the size).  The actual values in the
BTree,
if they are Persistent, are not forced by the iteration to load their
state.