On 09/06/2017 02:13 PM, Ronald Oussoren wrote:
To be honest this sounds like a fairly crude hack. Updating the
__class__ of a module object feels dirty, but at least you get normal
behavior w.r.t. properties.
Okay. Obviously I disagree, I think it's reasonable. But I'll assume
you're -1.
Why is there no mechanism to add new descriptors that can work in this
context?
I've updated the prototype to add one. I added it as
"collections.abc.InstanceDescriptor"; that's a base class you can
inherit from, and then your descriptor will work in a module.
Bikeshedding the name is fine.
BTW. The interaction with import is interesting… Module properties
only work as naive users expect when accessing them as attributes of
the module object, in particular importing the name using “from module
import prop” would only call the property getter once and that may not
be the intended behavior.
I spent a fair amount of time thinking about this. The short answer is:
we /could/ fix it. We /could/ make it so that "from x import y", when
x.y is an instance descriptor, ensures that y honors the descriptor
protocol when referenced. We'd have to do it for three contexts:
* global scope (aka module scope)
* class scope
* function scope
The first two are pretty similar; create a proxy object that retains the
module instance so it remains "bound" to that. The third one is
trickier; it'd mean a new bytecode (LOAD_FAST_DESCRIPTOR), but it
wouldn't slow down people who didn't use it.
Anyway, long story short, I think this would be worse than simply having
"from x import y" only calling the getter once. As the Zen says:
special cases aren't special enough to break the rules.
//arry/
_______________________________________________
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
