general problem when subclassing a built-in class

[Owen Jacobson]

On 2010-12-22 20:22:36 -0500, kj said:

> Suppose that you want to implement a subclass of built-in class, to
> meet some specific design requirements.
> 
> Where in the Python documentation can one find the information
> required to determine the minimal[1] set of methods that one would
> need to override to achieve this goal?

(Rest elided.)

The short answer is that you can't everything you want.

If some behaviour or implementation detail isn't documented, you can't 
make any assumptions about how a class works, even if you really want 
to. Whatever you figure out by "educated guesswork" (or, even better, 
reading the source) is, absent documentation, not guaranteed, and 
behaviour that's not guaranteed can and will change whenever the code's 
maintaners feel like it. This is true for for builtins, for things in 
the standard library, and for things in competently-maintained third 
party libraries.

Requiring that every class document its internals extensively enough to 
permit subclasses to modify behaviour in totally arbitrary ways has to 
be balanced against allowing each class's interface to usefully 
abstract its internal workings. Especially in a duck-typed language 
like Python, there's very little need for subclassing simply to 
intercept one or two method calls, and the resulting composition-based 
system is both more flexible and, being based on documented and stable 
interfaces, easier to maintain and support.

Subclassing is a powerful tool, not suited to every design problem. In 
your case (tracking timestamps in a dict-like container), you're 
probably better off implementing your own dict-like container, with 
support for as much or as little of the protocol you want. You can do 
that without subclassing dict: the protocol for dict is not difficult 
to implement, especially if your backing storage is a real dict.

What forces do you imagine require you to use a subclass for this?

-o