On Nov 16, 10:32 am, Steve Howell <showel...@yahoo.com> wrote: > On Nov 16, 2:35 am, Carl Banks <pavlovevide...@gmail.com> wrote: > > > > > On Nov 15, 2:52 pm, Steve Howell <showel...@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 -- http://mail.python.org/mailman/listinfo/python-list
