> In article <1069214841.6983.59.camel at localhost.localdomain>, > Jeremy Hylton <jeremy at alum.mit.edu> wrote: > > > The change was reported on python-dev, but apparently got left out of > > the NEWS file. Here are the details: > > http://mail.python.org/pipermail/python-dev/2003-April/034605.html [Good sleuthing, Jeremy!] > Thanks! Now that you mention it, I vaguely remember something of that > discussion. But the messages there seem to be mostly or entirely about > preventing __setattr__ on built-in types (justifiably called "evil" in > the thread) while the code I needed this for was to do it on my own > types. Was there some other discussion about preventing > object.__setattr__ on non-builtins or was this just an unintended > consequence? Not that it matters much now, it's done... Blame it on Carlo Verre. :-) The fix requires that whenever a built-in type derived from object overrides __setattr__, you cannot call object.__setattr__ directly, but must use the more derived built-in type's __setattr__. This is reasonable IMO, and is now enforced in 2.2.x as well. > Of course, all of this has led me to realize that my code was > unnecessarily obscure: I should have just used setattr(cls,...) :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4