[ZODB-Dev] BTrees and ZODB simplicity

Jim Fulton jim at zope.com
Mon Jul 22 15:42:40 CEST 2013


On Mon, Jul 22, 2013 at 8:11 AM, Christian Tismer <tismer at stackless.com> wrote:
> On 22.07.13 13:13, Jim Fulton wrote:
>>
>> On Sat, Jul 20, 2013 at 11:43 PM, Christian Tismer <tismer at stackless.com>
>> wrote:
>>>
>>> Third rant, dear Zope-Friends (and I mean it as friends!).
>>>
>>> In an attempt to make the ZODB a small, independant package, ZODB
>>> has been split into many modules.
>>
>> Maybe not as many as you think:
>> persistent, transaction, ZEO, ZODB and BTrees.
>>
>> 5 <shrug>
>>
>>> I appreciate that, while I think it partially has the opposite effect:
>>>
>>> - splitting BTrees apart is a good idea per se.
>>>     But the way as it is, it adds more Namespace-pollution than benefits:
>>>
>>>     To make sense of BTrees, you need the ZODB, and only the ZODB!
>>>     So, why should then BTrees be a top-level module at all?
>>>
>>>     This does not feel natural, but eavesdropping, pretending as
>>> something
>>>     that is untrue.
>>>
>>> I think:
>>>
>>>   - BTrees should either be a ZODB sub-package in its current state,
>>>
>>>   - or a real stand-alone package with some way of adding persistence as
>>>     an option.
>>
>> I don't agree that because a package depends on ZODB
>> it should be in ZODB.  There are lots of packages that depend
>> on ZODB.
>
>
> This is generally true. In the case of BTrees, I think the ZODB
> is nothing without BTrees, and BTrees make no sense without
> a storage and carry those _p_<attributes> which are not optional.

This is true of every class that subclasses Persistent.

>
> BTrees would make more sense as a standalone package if the persistence
> model were pluggable. But that is also theoretical because I don't see
> right now how to split that further with all the C code.

Well, it's definitely possible.  Early in the evolution of BTrees, there we
ifdefs that turned off dependence on persistence.

But even with the dependence on Persistent, their still perfectly usable without
storing them in a database.  Their use is just a lot more compelling
in the presence
of a database.

...

>> I agree with your sentiments about namespace pollution.
>> You and I may be the only ones that care though .3 ;).
>>
>
> Yay, actually I care mainly because just trying 'pip install ZODB'
> spreads out n folders in my site-packages, and 'pip uninstall ZODB' leaves
> n-1
> to pick the names by hand. That's why I want things nicely grouped ;-)

<shrug>

Maybe you should use virtualenv or buildout so as to leave your site-packages
alone.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton


More information about the ZODB-Dev mailing list