If you're inheriting from dict to extend its behavior, there are a lot of side effects with that, and it's recommended to use https://docs.python.org/3/library/collections.html#collectio... instead.
If you're inheriting from dict to extend its behavior, there are a lot of side effects with that, and it's recommended to use https://docs.python.org/3/library/collections.html#collectio... instead.
From right above where you linked to:
> 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.
Sounds like (unless you need the dict as a separate data member) this class is a historical artefact. Unless there's some other issue you know of not mentioned in the documentation?
dict doesn't follow the usual object protocol, and overloaded methods are runtime dependent. It's only guaranteed that non-overloaded methods are resolved least surprisingly.
I think you mean overridden (i.e. defined in both base class and derived class) rather than overloaded (i.e. defined more than once in a single place but with different argument types, as least from a typing point of view [1]). Your comment seriously confused me till I figured that out.
[1] https://typing.python.org/en/latest/spec/overload.html
Even then, to be honest I'm a bit sceptical. Can you point at a link in the official documentation that says overriding methods of dictionaries may not work? I would have thought the link to UserDict would have mentioned that if true. What do you mean they are "runtime dependent"?
See Chapter 14 of "Fluent Python", 2nd Edition by Luciano Ramalho. He details this under the heading "Subclassing Built-In Types Is Tricky."
UserDict isn't just some historical artifact of a bygone era like some of the posters below are miscorrecing me on.
It's unreasonable to ask me to chase down a reference in a book but I did it anyway because I was really curious.
It doesn't support what you said in your previous comment. It seemed to suggest that any calls to your overridden methods might magically use the base class instead, even when directly called from application code. But the book says something very different:
> The code of the built-ins (written in C) usually does not call methods overridden by user-defined classes.
But that is nothing to do with them being built-in classes or even being written in C. Any class, even written in pure Python, is not guaranteed to implement any of its methods in terms of other public methods, even when it's possible to do that. It just depends on how it's implemented.
Indeed that's true even for UserDict. It's no longer implemented in pure Python, but if you look at the 2.7 version [1], which was, you can see some methods implemented in terms of others (e.g. get() uses `key not in self` and `self[key]`) and others that aren't (e.g. keys() just uses self.dict.keys() rather than being implemented in terms of self.items()).
There was even a breaking change in Python 3.12 to which other methods UerDict.__getitem__() uses in its implementation [2]. I can sort of see some utility to UserDict but it seems at least as unpredictable as deriving from built in dict so it doesn't really buy you much. Either way, the only really safe way to use them is to override all methods that you want to behave differently.
[1] https://github.com/enthought/Python-2.7.3/blob/master/Lib/Us...
[2] https://github.com/python/cpython/issues/105524
No, that is not the recommendation. People routinely and reliably inherit from dict.
The UserDict class is mostly defunct and is only still in the standard library because there were a few existing uses that were hard to replace (such as avoiding base class conflicts in multiple inheritance).
Ah, Python. The language where nobody agrees on the right way to do things, ans just does their own instead. Five ways to describe an object of a certain shape? Six package managers, with incompatible but overlapping ways to publish packages, but half of them without a simple way to update dependencies? Asynchronous versions of everything? Metaprogramming that makes Ruby blush? Yes! All of it! Lovely.
UserDict is not formally deprecated but it will be someday, so code that relies on it is not future-proof.