29

What are advantages of using UserDict class?

I mean, what I really get if instead of

class MyClass(object):
    def __init__(self):
        self.a = 0
        self.b = 0
...
m = MyClass()
m.a = 5
m.b = 7

I will write the following:

class MyClass(UserDict):
    def __init__(self):
        UserDict.__init__(self)
        self["a"] = 0
        self["b"] = 0
...
m = MyClass()
m["a"] = 5
m["b"] = 7

Edit: If I understand right I can add new fields to an object in a runtime in both cases?

m.c = "Cool"

and

m["c"] = "Cool"
martineau
  • 119,623
  • 25
  • 170
  • 301
legesh
  • 2,097
  • 5
  • 19
  • 23

4 Answers4

45

UserDict.UserDict has no substantial added value since Python 2.2, since, as @gs mention, you can now subclass dict directly -- it exists only for backwards compatibility with Python 2.1 and earlier, when builtin types could not be subclasses. Still, it was kept in Python 3 (now in its proper place in the collections module) since, as the docs now mention,

The need for this class has been partially supplanted by the ability to subclass directly from dict; however, this class can be easier to work with because the underlying dictionary is accessible as an attribute.

UserDict.DictMixin, in Python 2, is quite handy -- as the docs say,

The module defines a mixin, DictMixin, defining all dictionary methods for classes that already have a minimum mapping interface. This greatly simplifies writing classes that need to be substitutable for dictionaries (such as the shelve module).

You subclass it, define some fundamental methods (at least __getitem__, which is sufficient for a read-only mapping without the ability to get keys or iterate; also keys if you need those abilities; possibly __setitem__, and you have a R/W mapping without the ability of removing items; add __delitem__ for full capability, and possibly override other methods for reasons of performance), and get a full-fledged implementation of dict's rich API (update, get, and so on). A great example of the Template Method design pattern.

In Python 3, DictMixin is gone; you can get almost the same functionality by relying on collections.MutableMapping instead (or just collections.Mapping for R/O mappings). It's a bit more elegant, though not QUITE as handy (see this issue, which was closed with "won't fix"; the short discussion is worth reading).

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • 7
    since '09 things moved a bit in python 3, and DictMixin is back: http://docs.python.org/library/userdict.html#UserDict.DictMixin - though MutableMapping is indeed suggest for most uses. – Stefano Jun 29 '11 at 12:17
  • 12
    Is this still valid? Reading "Fluent Python", the author recommends subclassing UserDict because "major caveat: the code of the built-ins (written in C) does not call special (magic) methods overridden by user-defined classes". This books covers 3.x but does this warning not apply to 2.7 as well? – JL Peyret Feb 05 '16 at 19:50
  • 3
    @Stefano: There is not now, and I'm pretty sure there has never been, any DictMixin in Python 3's standard library. The link you gave was at the time a link to the Python 2.7.2 documentation (currently a 404). – Nick Matteo Jun 13 '16 at 17:50
  • @Kundor you seem to be right, though I am left wondering why would I have posted a py2 doc link at the time. There's https://docs.python.org/3/library/collections.html#collections.UserDict in py3, maybe I got confused. Thanks for pointing that out! – Stefano Jun 14 '16 at 14:12
  • 3
    I see the UserDict in the official Python 3 documentation https://docs.python.org/3/library/collections.html#collections.UserDict but don't see anything about MutableMapping. Most likely, the answer is outdated. – Vladimir Chub Oct 31 '19 at 06:42
8

Subclassing the dict gives you all the features of a dict, like if x in dict:. You normally do this if you want to extend the features of the dict, creating an ordered dict for example.

BTW: In more recent Python versions you can subclass dict directly, you don't need UserDict.

Georg Schölly
  • 124,188
  • 49
  • 220
  • 267
6

It's tricky to overwrite dict correctly, while UserDict makes it easy. There was some discussion to remove it from Python3, but I believe it was kept for this reason. Example:

class MyDict(dict):

  def __setitem__(self, key, value):
    super().__setitem__(key, value * 10)


d = MyDict(a=1, b=2)  # Oups MyDict.__setitem__ not called
d.update(c=3)  # Oups MyDict.__setitem__ not called
d['d'] = 4  # Good!
print(d)  # {'a': 1, 'b': 2, 'c': 3, 'd': 40}

UserDict inherit collections.abc.MutableMapping, so don't have those drawback:

class MyDict(collections.UserDict):

  def __setitem__(self, key, value):
    super().__setitem__(key, value * 10)


d = MyDict(a=1, b=2)  # Good: MyDict.__setitem__ correctly called
d.update(c=3)  # Good: MyDict.__setitem__ correctly called
d['d'] = 4  # Good
print(d)  # {'a': 10, 'b': 20, 'c': 30, 'd': 40}
Conchylicultor
  • 4,631
  • 2
  • 37
  • 40
5

Well, as of 3.6 there are certainly some disadvantages, as I just found out. Namely, isinstance(o, dict) returns False.

    from collections import UserDict

    class MyClass(UserDict):
        pass

    data = MyClass(a=1,b=2)

    print("a:", data.get("a"))
    print("is it a dict?:", isinstance(data, dict))

Not a dict!

a: 1
is it a dict?: False

Change to class MyClass(dict): and isinstance returns True.

However... with UserDict you can step into its implementation.

(pdb-ing into functions/methods is an easy way to see exactly how they work)


#assumes UserDict

di = MyClass()

import pdb

#pdb will have work if your ancestor is UserDict, but not with dict
#since it is c-based
pdb.set_trace()
di["a"]= 1

JL Peyret
  • 10,917
  • 2
  • 54
  • 73
  • 1
    While UserDict does not inherit from a dictionary, the `data` attribute that stores the dict for UserDict objects is a normal dict and can be tested such as `isinstance(mydict.data, dict)` – LightCC Mar 14 '22 at 03:45