> The implication here is that .update() does not in turn use
> .__setitem__(), which I find a bit surprising.
It's never wise to make assumptions about this sort of thing.
Every method in a class or type is allowed to directly access
or modify its private, internal data. The implementation is
free to choose whether to limit that access to a few accessors
(i.e. getitem, setitem, delitem, len) or to let all of the
methods have direct access to the underlying data structure.
Even if accessors were used, the choice would be arbitrary
(perhaps delitem() gets implemented in terms of pop() or somesuch).
This is a basic for OO programming. Unless the class documentation
promises to use particular hooks, the implementation is free to
change in any way that doesn't violate the published API (this is
one of the benefits of encapsulation and abstract data types).
In general, if a subclass is overriding, rather than extending,
then it should override *every* method that could be affected.
On Wed, 5 Aug 2009 06:01 am kj wrote:
> In <(E-Mail Removed) om.au> Steven
> D'Aprano <(E-Mail Removed)> writes:
>>I also have a series of unit tests for it if you're interested in them.
> Actually, come to think of it, I think I'll take you up on this.
> I'd love to see those tests. Unit testing in Python is in area I
> need to work on.