On Nov 16, 10:11 pm, Carl Banks <pavlovevide...@gmail.com> wrote: > 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. >
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. -- http://mail.python.org/mailman/listinfo/python-list