[ZODB-Dev] BTrees package problems

[Christian Tismer]

Hey Jim,

On 23.07.13 19:18, Jim Fulton wrote:
> On Mon, Jul 22, 2013 at 9:06 PM, Christian Tismer <tismer at stackless.com> wrote:
> ...
>>>> Actually, I would like to add a callable-check instead, to allow for more
>>>> flexible derivatives.
>>> 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
> use case.

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
>> field
>> 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
> them writable.
>
> 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
> over.
>

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 
cycles are
    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
sub-classing built-ins.

-- 
Christian Tismer             :^)   <mailto:tismer at 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/