overriding __getitem__ for a subclass of dict
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