On Mon, Sep 11, 2017 at 6:04 PM, Larry Hastings <larry@hastings.org> wrote:

On 09/11/2017 08:44 AM, Guido van Rossum wrote:

I worry that in the end @property isn't general enough and the major use cases end up still having to use __class__ assignment, and then we'd have a fairly useless feature that we cant withdraw, ever.

What can I say--I don't have that worry ;-)

As previously mentioned in this thread, I counted up uses of property, __getattr__, and __getattribute__ in 3.7/Lib. I grepped for the following strings, ignored pydoc_data/topics.py, and got these totals:

"@property" 375 hits
"def __getattr__" 28 hits
"def __getattribute__(" 2 hits
@property seems pretty popular.

I saw that the first time but it doesn't address my worry. (I don't feel like explaining the worry again though, I feel I've done all I can.)

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.

I don't understand the question, or the answer. (And finding the prototype is taking longer than writing this email.)

Ronald was basically asking: what about user classes? The first revision of the prototype didn't provide a way to write your own instance descriptors. The only thing that could be a instance descriptor was property. So, I updated the prototype and added collections.abc.InstanceDescriptor, a base class user classes can inherit from that lets them be instance descriptors.

I still don't follow. How does one use InstanceDescriptor? Is this still about modules, or is it a generalization of properties for non-module instances? (If it is specific to modules, why doesn't it have "module" in its name? Or if it's not, why is it in this discussion?)

The prototype is linked to from the PEP; for your convenience here's a link:

https://github.com/larryhastings/cpython/tree/module-properties

I found that link in the PEP, but it's just a branch of a fork of cpython. It would be easier to review the prototype as a PR to upstream cpython.

--Guido van Rossum (python.org/~guido)