> I just noticed two things about persistent.PersistentMapping:
> - It inherits from UserDict.UserDict. Is there any reason not to
> inherit from dict directly, given that this has been possible
> since Python 2.3 IIRC?
Try it ;-). Or try to derive a class from, say, both `int` and `str` --
same outcome. Ah, good, Jeremy already explained this, so I'll stop there.
His other point is also on target: even if it were possible, it wouldn't
work as you expect. Subclassing from builtin C types works well if you're
adding _new_ methods, or additional data members, but is an unpredictable
crapshoot if you're trying to change behavior of pre-existing methods.
Dicts in particular are very heavily used by the Python implementation, and
tons of Python's C code invokes base dict methods directly, unwilling to
endure the expense of checking for overrides. Python's UserDict docs are
The need for this class has been largely supplanted by the
ability to subclass directly from dict ...
> - Not all methods of the mapping interface are handled. In particular,
> there's no reason not to handle pop() as popitems() is handled.
> Unhandled methods that change the content of the dict lead to
> especially nasty bugs as they seem to work OK during a transaction
> while their effect is not permanent.
I agree pop() should be added. Work up a patch, or at least open a bug
Note that there are two relevant classes, PersistentDict and
PersistentMapping. The code duplication there sucks (particularly because
they can-- and do --get out of synch), and one of them should be deprecated.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org