Extend `cached_property` to let the user select the attribute name

[clayote]

Feature or enhancement

Proposal:

Use case

My program has a lot of objects that are nearly stateless of themselves, but which have properties that instantiate richer objects that may have lots of state, including arbitrary data provided by the user. I wanted to use @cached_property to keep most of the objects nice and light, and only allocate much memory when the user refers to those properties.

Problem

The objects in question have the __slots__ attribute. @cached_property doesn't work with that.

Solution

I have a pull request incoming to add behavior to @cached_property so that if it's called like

class Something:
    __slots__ = ("_spam",)

    @cached_property("_spam")
    def eggs(self):
        return {"ham": "delicious"}

beans = Something()
print(beans.eggs)

this will cache {"ham": "delicious"} in the "_spam" slot, but only at the very end, when we refer to beans.eggs.

This has the side effect that the eggs property can be assigned to other names. I don't need this, but I couldn't think of a reason to forbid it.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-141216 Extend functools.cached_property so the user can select the attrname #141217

[picnixz]

The objects in question have the slots attribute. @cached_property doesn't work with that.

In this case, change the __slots__. The docs for cached_property require a __dict__ to exist.
Sorry but I don't think it's useful and would recommend writing your own cached_property. It goes against the semantics of a cached property as well.

[clayote]

Sure, it's not necessary, in the sense that you can write

class Something:
    __slots__ = ("_spam",)

    @property
    def eggs(self):
        if not hasattr(self, "_spam"):
            self._spam = {"beans": "delicious"}
        return self._spam

to much the same effect. This just means that any initialization I have to do for the cached object is more indented.

Likewise, when there's no __slots__, one may as well write

class Something:
    @property
    def eggs(self):
        if not hasattr(self, "_spam"):
            self._spam = {"beans": "delicious"}
        return self._spam

As I, in fact, did, many times over, before I found @cached_property.

I'm glad that @cached_property was added to the standard library, though. When you have many of them, it makes the code easier to read. Python has a lot of niceties like that, which is part of what makes it my favorite language. I saw an opportunity to add an additional bit of syntactic sugar, so I did it, and it's made my own code nicer to look at.

Please consider reopening this issue.

[picnixz]

No. I will not reconsider such addition that IMO does not make the code more readable as it creates an additional cognitive load and indirection. I suggest you to write your own pypi package for that if you want to have it in your projects