[ZODB-Dev] PersistentMapping

[Tim Peters]

[Thomas Lotze]
> 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
dreaming here:

    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
report?

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.