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. ;) 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 that. -- http://mail.python.org/mailman/listinfo/python-list
