On 09/06/2017 09:45 AM, Guido van
Rossum wrote:
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