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