overriding __getitem__ for a subclass of dict

[Steve Howell]

On Nov 16, 10:11 pm, Carl Banks <pavlovevide... at gmail.com> wrote:
> 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.
>

I am sorry having for a narrow mindset, and I apologize for not
seeming to realize how much extra code would go into the Python
codebase to allow me to hook into attribute lookups after
instantiation in debugging/tracing code.