overriding __getitem__ for a subclass of dict

Steve Howell showell30 at yahoo.com
Mon Nov 16 19:32:19 CET 2009

On Nov 16, 2:35 am, Carl Banks <pavlovevide... at gmail.com> wrote:
> On Nov 15, 2:52 pm, Steve Howell <showel... at yahoo.com> wrote:
> > Does anybody have any links that points to the rationale for ignoring
> > instance definitions of __getitem__ when new-style classes are
> > involved?  I assume it has something to do with performance or
> > protecting us from our own mistakes?
> "Not important enough to justify complexity of implementation."
> I doubt they would have left if out of new-style classes if it had
> been straightforward to implement (if for no other reason than to
> retain backwards compatibility), but it wasn't.  The way attribute
> lookups work meant it would have required all kinds of double lookups
> and edge cases.  Some regarded it as dubious to begin with.  And it's
> easily worked around by simply having __getitem__ call another method,
> as you've seen.  Given all this it made better sense to just leave it
> out of new-style classes.

Actually, the __getitem__ workaround that I proposed earlier only
works on subclasses of dict, not dict themselves.  So given a pure
dictionary object, it is impossible to hook into attribute lookups
after instantiation in debugging/tracing code.  I know it's not a
super common thing to do, but it is a legitimate use case from my
perspective.  But I understand the tradeoffs.  They seem kind of 20th
century to me, but with Moore's Law declining and all, maybe it's a
bad time to bring up the "flexibility trumps performance"
argument. ;)  The backward compatibility argument also seems a little
dubious, because if anybody *had* put __getitem__ on a dictionary
instance before, it would have already been broken code, and if they
hadn't done it, there would be no semantic change, just a performance
hit, albeit a pervasive one.

> Unfortunately not all such decisions and justifications are collected
> in a tidy place.

Yep, that's why I was asking here.  I figured somebody might remember
a thread on python-dev where this was discussed, or something like

More information about the Python-list mailing list