On Wed, Sep 13, 2017 at 11:49 AM, Guido van Rossum <gu...@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__. (I guess for full property emulation you'd also need to override __setattr__ and __dir__, but I don't know how important that is.) 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. 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. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com