On Wed, Sep 13, 2017 at 2:00 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Sep 13, 2017 at 11:49 AM, Guido van Rossum <guido@python.org> wrote:
Why not adding both? Properties do have their uses as does __getattr__.
In that case I would just add __getattr__ to module.c, and add a recipe or perhaps a utility module that implements a __getattr__ you can put into your module if you want @property support. That way you can have both but you only need a little bit of code in module.c to check for __getattr__ and call it when you'd otherwise raise AttributeError.
Unfortunately I don't think this works. If there's a @property object present in the module's instance dict, then __getattribute__ will return it directly instead of calling __getattr__.
Hm, that's a good point. One would have to introduce some kind of convention where you can write properties with a leading _: @property def _foo(): return 42 and then a utility __getattr__ like this: def __getattr__(name): g = globals() name = '_' + name if name in g: return g[name]() raise AttributeError(...)
(I guess for full property emulation you'd also need to override __setattr__ and __dir__, but I don't know how important that is.)
At that point maybe __class__ assignment is better.
We could consider letting modules overload __getattribute__ instead of __getattr__, but I don't think this is viable either -- a key feature of __getattr__ is that it doesn't add overhead to normal lookups. If you implement deprecation warnings by overloading __getattribute__, then it makes all your users slower, even the ones who never touch the deprecated attributes. __getattr__ is much better than __getattribute__ for this purpose.
Agreed. Alternatively we can have a recipe that implements @property support
using __class__ assignment and overriding __getattribute__/__setattr__/__dir__, so instead of 'from module_helper.property_emulation import __getattr__' it'd be 'from module_helper import enable_property_emulation; enable_property_emulation(__name__)'. Still has the slowdown problem but it would work.
The emulation could do something less drastic than __class__ assignment -- it could look for globals that are properties, move them into some other dict (e.g. __properties__), and install a __getattr__ that looks things up in that dict and calls them. def __getattr__(name): if name in __properties__: return __properties__[name]() raise AttributeError(...) Still, proposals for sys.py notwithstanding, I'm worried that all of this is a solution looking for a problem. Yes, it's a cute hack. But is it art? -- --Guido van Rossum (python.org/~guido)