GeezerVison

Thanks! It looks like this doesn't differ significantly from #23213, which has already been open for a while -- is that correct?

You are right, I somehow missed that one. I will compare the two PRs. If this one does not have any benefits I will close this one.

Thanks! It looks like this doesn't differ significantly from #23213, which has already been open for a while -- is that correct?

@AlexWaygood The two implementations are similar, but there are some differences so perhaps one is preferable over the other.

Looking at the different implementation performance, if it does not become too complex,
maybe _dispatch_method = None could be set on the singledispatchmethod class, then __get__ tries to assign __dict__ and fallsback on the _dispatch_method logic? May not be worth the extra complexity though

@eendebakpt Well, I will take a look at this PR by this weekend.

(I haven't had time yet, but I'd also like to take a look! I'll try to do so this weekend :)

Note that I don't see the same behaviour change with #23213 (as it's using a per-instance cache, rather than caching the same singledispatchmethod for all instances of Foo), so I generally prefer that approach. (But I like that you added a test for this PR, and the author of that PR hasn't responded to your review suggestion from a few weeks ago.)

Note that I don't see the same behaviour change with #23213 (as it's using a per-instance cache, rather than caching the same singledispatchmethod for all instances of Foo), so I generally prefer that approach. (But I like that you added a test for this PR, and the author of that PR hasn't responded to your review suggestion from a few weeks ago.)

If we decide the approach from this PR is not the right one (for the reasons mentioned above) and there is no response from the other author I can modify this PR and add another test for the behavior change.

The behavior from current main also differs a bit from "normal" methods, for example

from functools import singledispatch

class Foo:
    def bar(self):
        pass
    
    @singledispatchmethod
    def neg(self, arg): raise NotImplementedError
     
f = Foo()
print(f.bar is f.bar) # prints False
print(f.bar == f.bar) # prints True
print(f.neg is f.neg) # prints False on main, on this PR that changes to True
print(f.neg == f.neg) # prints False on main, which differs from the "normal" method bar
print(f.neg.register == f.neg.register) # prints True

F=Foo()
f.neg.bar=1 # works as expected
f.neg.bar # raises an error! that is really strange. for both PRs one can set f.neg.bar

In a certain sense with this PR the behavior is more like normal methods than current main, since we can now set f.neg.bar=1 and use than later. But the behaviour might be misleading since it is not per instance but per class.

A per object cache (like #85160) definitely feels like a safer option. I quickly checked whether a lru_cache on the __get__ might be an option to improve performance. The performance is good, but I think the behavior will be even stranger.

@eendebakpt

I have the same concern with @AlexWaygood
(Thank you Alex, for catching the side-effect, I was finding unexpected side-effects, and you pointed it out)

Well, IMO, the different result of the is operator doesn't look big issue for me. It is just for implementation detail.
(I think that is same as we don't recommend to compare int with is operator)
But assigning behavior is a big concern because this is quite a common operation and the user can meet unexpected behavior that the user didn't meet at older versions.

@eendebakpt
Would you like to re-submit the patch based on #23213 with a co-authored commit of the origin author?
cc @AlexWaygood

Closing in favor of #107148