Yes, I aware of this. Actually, I wrote also code and tests for__repr__, but have not included it in this PR, because the format of the repr may need a separate discussion. The current repr is an implementation artifact, and is not necessary the best.

@serhiy-storchaka I think this has caused a regression in Sphinx tests (sphinx-doc/sphinx#13360), though the onus may be on Sphinx to fix this -- noting for visibility though.

A

There is a bug here. It affects also pydoc,

I have found the cause, but it is late here, I'll fix this tomorrow.

Thanks!

A

So caching was abandoned all together?

With this, the call of__get__ is extremely slow as it constructs new instance every time. 420 ns every time for__get__ only +__call__ of instance is slower than the one ofFunctionType.

Or am I missing something?

Yes, we abandoned caching because of several issues with caching (we tried several options, they all have some issues).

However, with this PR performance the performance is almost as good (or sometimes better) than the caching approaches. The performance issue was only partly creating a new instance, but mostly getting attributes when updating attributes on the newly created instance.

Do you have any examples where performance is still an issue?

I find it a bit hard to believe that performance of this is good.

I have no personal interest in this, but just thinking in general. Don't think this sort of application is very common, but let's say an example:

fromfunctoolsimportsingledispatchmethod,singledispatch@singledispatchdefflatten_js(obj,parent_key=None):yieldobjifparent_keyisNoneelse (parent_key,obj)@flatten_js.registerdef_(obj:dict,parent_key=None):fork,vinobj.items():new_key= (k,)ifparent_keyisNoneelseparent_key+ (k,)yieldfromflatten_js(v,new_key)@flatten_js.registerdef_(obj:list,parent_key=None):fork,vinenumerate(obj):new_key= (k,)ifparent_keyisNoneelseparent_key+ (k,)yieldfromflatten_js(v,new_key)classA:@singledispatchmethoddefflatten_js(self,obj,parent_key=None):yieldobjifparent_keyisNoneelse (parent_key,obj)@flatten_js.registerdef_(self,obj:dict,parent_key=None):fork,vinobj.items():new_key= (k,)ifparent_keyisNoneelseparent_key+ (k,)yieldfromself.flatten_js(v,new_key)@flatten_js.registerdef_(self,obj:list,parent_key=None):fork,vinenumerate(obj):new_key= (k,)ifparent_keyisNoneelseparent_key+ (k,)yieldfromself.flatten_js(v,new_key)a=A()# ---./python.exe-mtimeit-s $S"list(a.flatten_js({'a': [1, 2, 3, [4]]}))"# 10µs./python.exe-mtimeit-s $S"list(flatten_js({'a': [1, 2, 3, [4]]}))"#  5µs

So for applications of low complexity such as this, half of the time spent is an overhead of constructing_singledispatchmethod_get instances and calling its__call__.

Yes, singledispatchmethod has an overhead. And caching does not solve it. If you have other solution, please open a new issue.

And caching does not solve it.

With this:

classsingledispatchmethod(functools.singledispatchmethod):def__set_name__(self,obj,name):self.attrname=namedef__get__(self,obj,cls=None):cache=obj.__dict__try:returncache[self.attrname]except:defmethod(*args,**kwargs):returnself.dispatcher.dispatch(args[0].__class__).__get__(obj,cls)(*args,**kwargs)cache[self.attrname]=methodreturnmethod./python.exe-mtimeit-s $S"list(a.flatten_js({'a': [1, 2, 3, [4]]}))"# 7 µs

So caching, at least for this case, results in 60% lower overhead.

If you have other solution, please open a new issue.

In terms of performance, caching as per#128648 (comment) had benefits - I have nothing else.

If anyone wants needs performance benefit of caching and the approach ofcached_property is acceptable,_singledispatchmethod_get caching can always be implemented. For my example, its time is 7.2 µs, to sum up:

singledispatch                   -  5µssingledispatchmethod             - 10µs (this PR)cached FuntionType               -  7µscached _singledispatchmethod_get -  7.2 µs