Paul Prescod wrote: > Performance is only one of the goals. Clarity is the more major > one. Safety is another. When you start combining __getattr__ with > multiply inherited base class __getattr__ and so forth you get > into a real mess. This proposal does not have that problem. You're doing some obsfucating here. Overriding a method with multiple base class implementations of that method with the desire to chain to one or more of the base class implementations of that method is a mess. It's not more of a mess because the method is named __getattr__. The obvious solution has nothing to do with the language - it's to use has-a instead of is-a. This proposal changes those semantics. Hooking an attribute masks anything in a base class with that name. That's probably a good thing, but it should be made explicit since that's not the way __getattr__ behaves. Similarly, there's a difference from __setattr__. If you assign to the instance.__dict__, the hook will no longer apply for that instance / attribute. Also note that while this is *safer* than __xxxattr__, it's still not *safe*. Infinite recursion is less likely, but still easily achieved. Truth-in-PEPs-ly y'rs - Gordon
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