On 23.07.13 19:18, Jim Fulton wrote:
On Mon, Jul 22, 2013 at 9:06 PM, Christian Tismer <tis...@stackless.com> wrote:
Actually, I would like to add a callable-check instead, to allow for more
I don't understand this.
Simple: I am writing BTree forests for versioned, read-only databases.
For that, I need a way to create a version of Bucket that allows to
override the _next field by maybe a callable.
Otherwise all the buckets are chained together and I have no way
to let frozen BTrees share buckets.
In retrospect, it might make more sense to do the chaining a level up.
Buckets themselves don't care about chaining. The tree wants buckets
to be chained to support iteration. I'm not really sure if that helps your
Yes I know.
I was thinking of a minimal-intrusive, minimal-overhead way to get it
without forking/re-writing, but I'm not settled, yet.
When I played with the structure, I was happy/astonished to see the _next
being writable and thought it was intended to be so.
It was not, in the end ;-)
It's clearly a bug. The code has a comment right above the attribute definition
stating that it's (supposed to be) read only, but the implementation makes
There doesn't seem to be anything that depends on writing this attribute.
I verified this by adding a fix and running the tests (in 3.10).
I know that it is a serious bug (by definition, since it causes a bus error)
but it also is not an urgent bug (because it needed me to find it at all).
Actually, I have a tendency to find them; the first time I look intensively
into a project that I like, this happens almost all the time.
Do you know Mr. Adrian Monk from that wonderful Monk series?
On software development, it seems to be just me. ::
"""It's a gift, and a curse."""
For what you're trying to do, I suspect you want to fork BTrees, or start
Starting over/forking is the easy but heavy way.
Before I do that, I will analyze everything and find out if it makes more
sense to share the existing code, which is (after my intense investigation
and analysis) very good and a highly optimized implementation.
It is my goal to
- either add to this quasi-perfect thing in a way that the overhead
below 1.8 percent, or
- find out that the benefit of a patched solution is too low to justify a
patch and do a re-write fork.
What I'm after is a way to over-ride the implementation by user code.
I did not yet check it this is implemented already, in the Python way of
Christian Tismer :^) <mailto:tis...@stackless.com>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776 fax +49 (30) 700143-0023
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org