On 09/06/2017 09:45 AM, Guido van Rossum wrote:
So we're looking for a competing PEP here. Shouldn't be long, just summarize the discussion about use cases and generality here.
I don't think it's necessarily a /competing/ PEP; in my opinion, they serve slightly different use cases. After all, property (and __getattribute__) were added long after __getattr__; if __getattr__ was a reasonable solution for property's use cases, why did we bother adding property?
One guiding principle I use when writing Python: if I need to provide an API, but there's conceptually only one of the thing, build it directly into a module as opposed to writing a class and making users use an instance. (For example: the random module, although these days it provides both.) So I see the situation as symmetric between modules and classes. What is the use case for property / __getattr__ / __getattribute__ on a module? The same as the use case for property / __getattr__ / __getattribute__ on a class.
Excluding Lib/test, there are 375 uses of "@property" in the stdlib in trunk, 60 uses of __getattr__, and 34 of __getattribute__. Of course, property is used once per member, whereas each instance of __getattr__ and __getattribute__ could be used for arbitrarily-many members. On the other hand, it's also possible that some uses of __getattr__ are legacy uses, and if property had been available it would have used that instead. Anyway I assert that property is easily the most popular of these three techniques.
TBH I forgot the specific use case that inspired this--it's on a project I haven't touched in a while, in favor of devoting time to the Gilectomy. But I can cite at least one place in the standard library that would have been better if it'd been implemented as a module property: os.stat_float_times().
//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
