On Aug 19, 2015, at 23:54, Thomas Güttler wrote:

I think it would be great to have properties for classes in Python2 and Python3

Well, Python 2 has been closed to new features for years now. Anyway, if you add a property to a metaclass, it does exactly what you want. (After all, a metaclass is the type of a class object, which is where you put class descriptors.)

There are some "patterns" to get this working:

http://stackoverflow.com/questions/5189699/how-can-i-make-a-class-property-i...

http://stackoverflow.com/questions/128573/using-property-on-classmethods

... but an official solution would be more "zen of python".

Do you think properties for classes would be useful?

If it works for classes, then it could be used for modules, too?

Modules are a more serious problem, because there's no immediate way to specify the type for a module object. You can work around it by, e.g., declaring a module subclass, copying the module's dict to an instance of that subclass, then replacing the entry in sys.modules, but this is more than a little ugly. There have been proposals to allow modules to specify a type (e.g., something similar to the way __metaclass__ worked in 2.x), and to make it easier to hook the import machinery to create modules of a custom type, and probably other variations on this. You might want to search this list and -dev for previous ideas, to find one you think should be reconsidered.

Regards, Thomas Güttler

PS: my first post via google groups web interface did not arrive here. That's the second try. Now via mail.

-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Aug 20, 2015 at 2:54 AM, Thomas Güttler wrote:

I think it would be great to have properties for classes in Python2 and Python3

There are some "patterns" to get this working:

http://stackoverflow.com/questions/5189699/how-can-i-make-a-class-property-i...

http://stackoverflow.com/questions/128573/using-property-on-classmethods

... but an official solution would be more "zen of python".

I recently added my own implementation of this here: https://github.com/astropy/astropy/blob/master/astropy/utils/decorators.py#L... (which I think is pretty elegant--moreso than the ones on those SO links, but I'm biased :) However, my version is only for read-only properties. It could easily be extended to support writeable properties, but as pointed out elsewhere that requires the container class to have a custom metaclass :/

Do you think properties for classes would be useful?

Yes--given my recent experience in trying to implement this I feel like it should be supported in Python. Just as Python ships with a builtin classmethod, I think there should be a builtin classproperty that is special-cased to work without a custom metaclass. I think it's a special case that's special enough IMO.

If it works for classes, then it could be used for modules, too?

With a ModuleType subclass, sure, but that's a separate, and thornier issue :) Erik

How are metaclasses unpythonic? This is one of the more defining features of python. There will be no way to properly implement this without moving the descriptor up to the metaclass. When thinking about metaclasses, it is often best to just think of them as classes and other types as instances. On Thu, Aug 20, 2015 at 11:20 AM, Sven R. Kunze wrote:

Sounds more like Thomas is looking for an Pythonic solution without messing around with sys.modules or metaclasses.

I personally like the proposals on StackOverflow and don't see why it couldn't be made to work out of the box:

class MyClass: @classproperty def prop(cls): return '42'

# module property @property def prop(mod): return '42'

On 20.08.2015 09:47, Nathaniel Smith wrote:

...

On Thu, Aug 20, 2015 at 12:20 AM, Andrew Barnert via Python-ideas wrote:

...

Modules are a more serious problem, because there's no immediate way to specify the type for a module object. You can work around it by, e.g., declaring a module subclass, copying the module's dict to an instance of that subclass, then replacing the entry in sys.modules, but this is more than a little ugly.

There have been proposals to allow modules to specify a type (e.g., something similar to the way __metaclass__ worked in 2.x), and to make it easier to hook the import machinery to create modules of a custom type, and probably other variations on this. You might want to search this list and -dev for previous ideas, to find one you think should be reconsidered.

This is already done :-). Python 3.5 allows a module to contain code like:

class MetaModule(types.ModuleType): @property def some_attribute(self): print("Accessing module.some_attribute") return 1

sys.modules[__name__].__class__ = MetaModule

See also

https://pypi.python.org/pypi/metamodule

for utility code and a polyfill back to ancient Pythons.

-n

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Am 20.08.2015 um 17:20 schrieb Sven R. Kunze:

Sounds more like Thomas is looking for an Pythonic solution without messing around with sys.modules or metaclasses.

I personally like the proposals on StackOverflow and don't see why it couldn't be made to work out of the box:

class MyClass: @classproperty def prop(cls): return '42'

The following solution provides an @classproperty: http://stackoverflow.com/a/5191224/633961 I have not tried setting the value yet, but getting the value works very fine. It would be great to have "@classproperty" even in Python2. Or at least installable via pip. I am just a user in this case. I don't know about the best, cleanest, most efficient way to implement this. Regards, Thomas -- Thomas Guettler http://www.thomas-guettler.de/

I think that syntax would be fine, but then `type.__new__` would need to do something special with that to implement the setter protocol for the types. On Thu, Aug 20, 2015 at 11:34 AM, Thomas Güttler < guettliml@thomas-guettler.de> wrote:

Am 20.08.2015 um 17:27 schrieb Joseph Jevnik:

...

How are metaclasses unpythonic? This is one of the more defining features of python. There will be no way to properly implement this without moving the descriptor up to the metaclass. When thinking about metaclasses, it is often best to just think of them as classes and other types as instances.

Yes, metaclasses are a great feature for experts.

For me this syntax is the most readable:

class MyClass:

...

@classproperty def prop(cls): return '42'--

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Cached properties are trivially implemented class C: @property @lru_cache(None) def p(self): ... On Thu, Aug 20, 2015 at 11:57 AM, Sven R. Kunze wrote:

On 20.08.2015 17:31, Thomas Güttler wrote:

...

The following solution provides an @classproperty: http://stackoverflow.com/a/5191224/633961

I have not tried setting the value yet, but getting the value works very fine.

It would be great to have "@classproperty" even in Python2. Or at least installable via pip.

I am just a user in this case. I don't know about the best, cleanest, most efficient way to implement this.

Reminds me of cached_property: https://pypi.python.org/pypi/cached-property/0.1.5

I feel it could be useful to have a holistic solution (property + cached + instance,classes,modules) in the stdlib/Python somehow.

Best, Sven

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

What about 'staticproperties'? On 20.08.2015 18:07, Erik Bray wrote:

On Thu, Aug 20, 2015 at 11:57 AM, Sven R. Kunze wrote:

...

On 20.08.2015 17:31, Thomas Güttler wrote:

...

The following solution provides an @classproperty: http://stackoverflow.com/a/5191224/633961

I have not tried setting the value yet, but getting the value works very fine.

It would be great to have "@classproperty" even in Python2. Or at least installable via pip.

I am just a user in this case. I don't know about the best, cleanest, most efficient way to implement this.

Reminds me of cached_property: https://pypi.python.org/pypi/cached-property/0.1.5

I feel it could be useful to have a holistic solution (property + cached + instance,classes,modules) in the stdlib/Python somehow. Having something like a cached-property (or the lazy=True option in my classproperty implementation) is rather nice, but as Guido points out it's out of scope for a general implementation of @classproperty (it's also easy enough to implement memoization patterns outside the stdlib).

However, for (settable) @classproperty to work seamlessly, without having to involve custom metaclasses, would require a CPython implementation and probably a PEP. For in order for this to work it would have to be special-cased, since assignments to a class attribute don't normally go through <descriptor>.__set__.

Erik

Am 20.08.2015 um 18:42 schrieb Sven R. Kunze:

What about 'staticproperties'?

Yes, that sound good. In my case a read-only classproperty is all I need. I guess that is what you mean with "staticproperty". Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/

On 8/24/2015 6:07 AM, Thomas Güttler wrote:

Am 20.08.2015 um 17:29 schrieb Guido van Rossum:

...

I think it's reasonable to propose @classproperty as a patch to CPython. It needs to be C code. Not sure about the writable version. The lazy=True part is not appropriate for th he stdlib (it's just a memoize pattern).

What's the next step?

Open an issue on the tracker. Quote Guido's message above with list name, date, and thread name -- or pipermail archive url. Add python code below, or revision thereof, for someone to translate to C.

My knowledge of the programming language C is very limited. I am not able to write a patch for CPython.

I could write a patch which looks like this:

{{{ # From http://stackoverflow.com/a/5192374/633961

class classproperty(object): def __init__(self, f): self.f = f def __get__(self, obj, owner): return self.f(owner)

}}}

-- Terry Jan Reedy

Here is the created issue: http://bugs.python.org/issue24941 Please let me know if something is missing. Thomas Güttler Am 24.08.2015 um 19:17 schrieb Terry Reedy:

On 8/24/2015 6:07 AM, Thomas Güttler wrote:

...

Am 20.08.2015 um 17:29 schrieb Guido van Rossum:

...

I think it's reasonable to propose @classproperty as a patch to CPython. It needs to be C code. Not sure about the writable version. The lazy=True part is not appropriate for th he stdlib (it's just a memoize pattern).

What's the next step?

Open an issue on the tracker. Quote Guido's message above with list name, date, and thread name -- or pipermail archive url. Add python code below, or revision thereof, for someone to translate to C.

...

My knowledge of the programming language C is very limited. I am not able to write a patch for CPython.

I could write a patch which looks like this:

{{{ # From http://stackoverflow.com/a/5192374/633961

class classproperty(object): def __init__(self, f): self.f = f def __get__(self, obj, owner): return self.f(owner)

}}}

-- Thomas Guettler http://www.thomas-guettler.de/

On Thu, Aug 20, 2015 at 12:54 AM, Thomas Güttler wrote:

I think it would be great to have properties for classes in Python2 and Python3

As always there's a rich history to which we can turn: on the mailing lists and the issue tracker. The addition of a "class property" is not a new idea, which implies it *might* be worth pursuing, but only if the previous obstacles/objections are resolved. [1] Furthermore, composition of abc.abstractmethod and property/classmethod/staticmethod was added not that long ago. The evolution of that composition provides some context for what is appropriate here. [2] Note that first we added abc.abstractmethod, then abc.abstractclassmethod, and then proper composition (abc.abstractmethod + classmethod). Though it's subtly different than the abstractmethod case, I suggest we avoid adding "classproperty" and skip straight to getting the composition approach working in a similar way to abstractmethod [3]: class Spam: @classmethod @property def eggs(cls): return 42 [Note that the alternate composition order doesn't work out since property is a descriptor that resolves strictly against instances. Would that be obvious enough or a point of confusion?] Unfortunately, there is a problem with applying classmethod onto property. Obviously a property isn't a function such that "classmethod" is an accurately described modifier. This is more concretely problematic because the classmethod implementation directly wraps the decorated object in a method object. [4] In Python it would look like this: class classmethod: def __init__(self, func): self.func = func def __get__(self, obj, cls): return types.MethodType(self.func, cls) I expect that this is an optimization over calling self.func.__get__, which optimization was likely supported by the sensible assumption that only functions would be passed to classmethod. The naive implementation of classmethod would look more like this: class classmethod: def __init__(self, func): self.func = func def __get__(self, obj, cls): return self.func.__get__(cls, type(cls)) If that were the actual implementation then we wouldn't be having this conversation. :) So to get composition to work correctly we have 3 options: 1. switch to the less efficient, naive implementation of classmethod.__get__ 2. add "classproperty", which does the right thing 3. add "classresolved" (or similarly named), which resolves wrapped descriptors to the class rather than the instance I advocate for #3 over the others. It provides for broader application while not impacting the optimizations in classmethod (and it has a more accurate name). It would work similarly to the naive classmethod implementation (and work as a less efficient replacement for classmethod): class classresolved: def __init__(self, wrapped): self.wrapped = wrapped def __get__(self, obj, cls): try: getter = self.wrapped.__get__ except AttributeError: return self.wrapped return getter(cls, type(cls)) Note that wrapped data descriptors (like property) would behave as non-data descriptors since classresolved is itself a non-data descriptor. The case for making it a data descriptor can be treated separately, but I don't think that case is as strong. All this leads to some broader observations about useful, generic descriptors in the stdlib. I'll open a new thread for that conversation.

There are some "patterns" to get this working:

http://stackoverflow.com/questions/5189699/how-can-i-make-a-class-property-i...

http://stackoverflow.com/questions/128573/using-property-on-classmethods

... but an official solution would be more "zen of python".

Do you think properties for classes would be useful?

I think so. Here are use cases off the top of my head: * read-only class attrs * dynamically generated class attrs * lazily generated class attrs * class attrs that track access * class attrs that interact with a class registry * class attrs that replace themselves on the class upon first use * ... So basically stick in nearly all the use cases for properties, but applied to classes. The main difference is that a "class property" would be a non-data descriptor. Pursuing a data descriptor approach is debatably overreaching and potentially problematic. Note that normally bound class attrs still meet most needs, so any solution here should be cognizant of the possibility of providing an attractive nuisance here (and avoid it!).

If it works for classes, then it could be used for modules, too?

Module attribute access does not involve the descriptor protocol. There are ways to work around that to support descriptors (e.g. the module-replaces-itself-in-sys-modules trick), but that is an orthogonal issue. Furthermore, using some other mechanism than the descriptor protocol to achieve module "properties" isn't worth it ("special cases aren't special enough..."). -eric [1] Some examples from the history of the idea: (oct2005) https://mail.python.org/pipermail/python-list/2005-October/321426.html an attempt to implement classproperty (jan2011) https://mail.python.org/pipermail/python-ideas/2011-January/008950.html Enumeration of many permutations of decorators; proposal to add classproperty; Guido in favor; Michael shows a simple implementation (feb2014) http://bugs.python.org/issue20659 "To get the behaviour you're requesting, you need to use a custom metaclass and define the property there." [2] Changes relative to abc.abstractmethod: (apr2009) http://bugs.python.org/issue5867 Compose abc.abstractmethod and classmethod (changed to abc.abstractclassmethod)...Guido said "I object to making changes to the classmethod implementation." (mar2011) http://bugs.python.org/issue11610 Compose abc.abstractmethod and property/classmethod/staticmethod/ [3] https://docs.python.org/3/library/abc.html#abc.abstractmethod [4] https://hg.python.org/cpython/file/default/Objects/funcobject.c (cm_descr_get)