[Python-Dev] PEP 549: Instance Properties (aka: module properties) (original) (raw)
Guido van Rossum guido at python.org
Wed Sep 13 17:17:08 EDT 2017
- Previous message (by thread): [Python-Dev] PEP 549: Instance Properties (aka: module properties)
- Next message (by thread): [Python-Dev] PEP 549: Instance Properties (aka: module properties)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Sep 13, 2017 at 2:00 PM, Nathaniel Smith <njs at pobox.com> wrote:
On Wed, Sep 13, 2017 at 11:49 AM, Guido van Rossum <guido at 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 gname 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 modulehelper.propertyemulation import getattr' it'd be 'from modulehelper import enablepropertyemulation; enablepropertyemulation(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 propertiesname 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170913/648f57bb/attachment.html>
- Previous message (by thread): [Python-Dev] PEP 549: Instance Properties (aka: module properties)
- Next message (by thread): [Python-Dev] PEP 549: Instance Properties (aka: module properties)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]