Checkcached_property.__set_name__, it has some more stuff in it - might be needed here as well.

Hmm. The additions there prevent something like this:

@dataclass(frozen=True)class A:    value: int    @singledispatchmethod    def dispatch(self, x):        return id(self)    renamed_dispatch = dispatch # allowed? if so, how should it behave

The corresponding test for thecached_property for this is

But on current main renamingis allowed for the singledispatchmethod.

I am not sure here what the desired behavior is (and why)

If this implementation is desirable, maybe later someone who knows more about this can comment.

As far as I know, the only reason cached properties can't be renamed is because the cache is keyed by the attribute's name.

Allowing a rebind would disconnect the cached property from it's cached value.

Actually, I think you might want to either ignore renames or do something along these lines (ignoring error handling):

ifself.attrname:cache[name]=cache.pop(self.attrname)self.attrname=name

As far as I know, each binding shares the same instance of the descriptor, so as long as the cache key is constant, it should work no matter how many times it's been renamed.

Allowing a rebind would disconnect the cached property from it's cached value.

This is kind of the same situation.

If rename is allowed, then it would simply cache to the lastattrname. Drawback is that there is a small risk for unused cached methods.

I think it might be most straight forward to copy+pastecached_property.__set_name__. It does seem a sensible restriction. It comes at expense of flexibility, but personally, I have never run intothatTypeError.

Also, it will be easier to address changes/improvements when 2 implementations that use the same caching approach are aligned.

Does not it create a reference loop?obj refers tocache,cache refers to_method,_method refers to a cell which refers toobj.

Yes. But once there are no external references to the objectobj any more the garbage collector removes the objects. (the cache is on the objectobj, not on the singledispatchmethod itself or the class)

In the current main the caching is done on thesingledispatchmethod which keeps the generated methods alive.

Yes, the current situation is worse, it creates strong references singledispatchmethod -> _method -> obj.

Relying on the garbage collection is not good. This particular loop can be broken by using a weak reference to obj instead of obj. But a reference from a bound method to the object should be strong, otherwise some code will not work (there was a similar issue with TemporaryFile).

I am not sure how much this optimization saves. Are there other ways to achieve the same speed up, without creating reference loops?