durusmail: durus-users: Eliminate __dict__ from persistent btree, bnode, dict, list and set
Eliminate __dict__ from persistent btree, bnode, dict, list and set
Eliminate __dict__ from persistent btree, bnode, dict, list and set
2006-07-05
2006-07-05
2006-07-05
2006-07-06
2006-07-06
2006-07-06
XMPP/Jabber chatting (was: Re: [Durus-users] Eliminate __dict__ from persistent btree, bnode, dict, list and set)
2006-10-31
Re: XMPP/Jabber chatting
2006-10-31
Eliminate __dict__ from persistent btree, bnode, dict, list and set
Patrick K. O'Brien
2006-07-06
David Binger wrote:
>
> On Jul 5, 2006, at 9:27 PM, Patrick K. O'Brien wrote:
>
>> David Binger wrote:
>>>
>>> On Jul 5, 2006, at 7:59 PM, Patrick K. O'Brien wrote:
>>>
>>>>
>>>> I have one idea.  Instead of PersistentDict.data being a dict, it could
>>>> be a subclass of dict.  Then __setstate__ could test the incoming state
>>>> to see if it is a regular dict or our special subclass.  But that would
>>>> trade off physical disk savings against type inspection within
>>>> __setstate__, which gets called a lot.  I'm not sure that would be
>>>> worthwhile.  The alternative would be a one-time conversion routine.
>>>> Unless you think of something better.
>>>
>>> It does not help PersistentSet or PersistentList as your idea does,
>>> but it might be possible to make PersistentDict use the actual __dict__
>>> value as the dict instead of wrapping another dict instance.
>>>
>>> I think I remember trying to make PersistentDict be a dict as you
>>> suggest here, and I felt like it was getting difficult to understand.
>>
>> I'm not sure we're talking about the exact same thing.  My idea was
>> something like this:
>
> We're not.  I was thinking that *maybe* PersistentDict could be
> defined to use the normal self.__dict__ *directly* for holding
> keys and values instead of using any self.data, slot or otherwise.

Ah, right.  Now I'm with you.  Replacing 'data' with '__dict__' would:

* eliminate one dictionary,
* bring back the arbitrary attribute capability,
* reduce the physical file size, and
* complicate setstate (by bringing back the need to monitor delattr and
setattr)

But that trick wouldn't work for PList, PSet, BTree, or BNode.  And a
typical Schevo database has quite a few bnodes.

Personally, I don't think supporting arbitrary attributes is a very good
idea in the context of a database.  For the one example Mike gave,
dotted syntax support could be provided by custom __getattr__ and
__setattr__ methods on PDict.  If someone wanted arbitrary attributes on
PList, PSet, BTree or BNode I would be very curious to know why.

--
Patrick K. O'Brien
Orbtech       http://www.orbtech.com
Schevo        http://www.schevo.org
Louie         http://www.pylouie.org
reply