UserDict's has_key() and get() should use __getitem__()

[Hamish Lawson]

Andrew Dalke wrote:

>I don't believe your estimate, that UserDicts are usually
>derived "for the purpose of providing new definitions of
>setting and getting items", is correct.

It may well not be. When I reread what I'd written I see that
I've made more of a claim that I meant to regarding the reasons
why UserDict is subclassed, when I was really just venturing a
guess on that.

>In addition, in a good OO design, you should be able to use
>an instance of a derived class anywhere you use an instance
>of a base class.  Your example (a caseless Dict), changes
>how/when lookup failures occur.

An instance of CaselessDict could still be used wherever an
instance of UserDict could be, in the sense that it supports the
same operations. However if it's considered part of UserDict's
contract that unique strings should be able to be used as
separate keys, then it's true that CaselessDict violates this.
Perhaps this wasn't my best example.

>Then Python's UserDict is just an implementation of the
>AbstractUserDict base class. ... And because this is Python,
>it's easy to implement.

I see where you and Michael are coming from. And if UserDict
*is* considered an implementation of a (possibly notional)
abstract class, then I suppose it is reasonable for it to use an
implementation that it is more efficient. I suppose what I was
after was to have UserDict still provide a useful default
implementation (albeit a bit less efficient one*), but make it
more abstract (semi-abstract?) to make it more easily subclassed
and to let aspects of the default implementation be more readily
replaced.

* Do we know how much less efficient?

But so far my proposal doesn't seem to have won favour. Ah
well :-)

Thanks for your thoughts.

Hamish



* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!