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
--
http://mail.python.org/mailman/listinfo/python-list
