overriding __getitem__ for a subclass of dict

[Carl Banks]

On Nov 16, 10:32 am, Steve Howell <showel... at yahoo.com> wrote:
> 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. ;)

It's not performance, it's code complexity.

Implementing this would have to added a lot of extra code to the
Python codebase--more than you seem to realize--all in support of a
dubious behavior.  This would have meant more opporunities for bugs,
and an increased maintainence burden.


> 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.

Wrong.  It's only dubious from your narrow mindset that focuses on
your own problem and ignores the greater problem.  When new-style
classes were introduced, they made a decision that magic methods would
no longer work when defined on any instance.  It affected a *lot* more
than just your dictionary use-case.

So please spare me any suggestions that the change didn't carry a
significant backwards incompatibility.  It did, and they made the
change anyway.  That should tell you how difficult it would have been
to implement.


Carl Banks