On Apr 7, 2:40 pm, andrew cooke <and...@acooke.org> wrote: > Is that normal? I mean, OK, it's possible (and yes I forgot it could be > called directly), but is there any usual reason to do so?
It's common for subclasses to call their parent's __init__ method, so that should emulate dict as nearly as possible to help avoid surprises. For the most part, client code won't use __init__ directly because update() already provides equivalent functionality (but with a better name). For list.__init__(), the behavior is different. It clears the list, so someone may be using an __init__ call when it isn't practical to use the syntactic equivalents "del a[:]" or "a[:] = []". Outside those cases, I don't it is "normal", but who knows what future programmers will need to do? > I guess what I'm asking is: if I'm writing library code should I be this > careful? For the standard library, it pays to really think out the corner cases because you never know what people are going to rely on. The Liskov substitution principle asks us to make OrderedDict behave as much like dict as possible (so that OD's can be used a drop-in substitute when needed). Also subclassers tend to stress the API in ways that wouldn't be common for the base class. For standard library code, I think all the little things matter: * int(), bool(), list() etc all return a "zero" value when called with no arguments * the ordered dict code internally calls __update() instead of update() so that a subclass can override update() without breaking the constructor * eval(repr(obj)) should round-trip whereever possible * containers should behave reasonable well even if someone makes the container reference itself: a=[]; a.append(a) * classes should try to be pickable, copyable, and deepcopyable, etc ... Raymond -- http://mail.python.org/mailman/listinfo/python-list
