GeezerVison

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 of FunctionType.

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:

from functools import singledispatchmethod, singledispatch


@singledispatch
def flatten_js(obj, parent_key=None):
    yield obj if parent_key is None else (parent_key, obj)

@flatten_js.register
def _(obj: dict, parent_key=None):
    for k, v in obj.items():
        new_key = (k,) if parent_key is None else parent_key + (k,)
        yield from flatten_js(v, new_key)

@flatten_js.register
def _(obj: list, parent_key=None):
    for k, v in enumerate(obj):
        new_key = (k,) if parent_key is None else parent_key + (k,)
        yield from flatten_js(v, new_key)

class A:
    @singledispatchmethod
    def flatten_js(self, obj, parent_key=None):
        yield obj if parent_key is None else (parent_key, obj)

    @flatten_js.register
    def _(self, obj: dict, parent_key=None):
        for k, v in obj.items():
            new_key = (k,) if parent_key is None else parent_key + (k,)
            yield from self.flatten_js(v, new_key)

    @flatten_js.register
    def _(self, obj: list, parent_key=None):
        for k, v in enumerate(obj):
            new_key = (k,) if parent_key is None else parent_key + (k,)
            yield from self.flatten_js(v, new_key)

a = A()

# ---
./python.exe -m timeit -s $S "list(a.flatten_js({'a': [1, 2, 3, [4]]}))"    # 10µs
./python.exe -m timeit -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:

class singledispatchmethod(functools.singledispatchmethod):
    def __set_name__(self, obj, name):
        self.attrname = name

    def __get__(self, obj, cls=None):
        cache = obj.__dict__
        try:
            return cache[self.attrname]
        except:
            def method(*args, **kwargs):
                return self.dispatcher.dispatch(args[0].__class__).__get__(obj, cls)(*args, **kwargs)
            cache[self.attrname] = method
            return method

./python.exe -m timeit -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 of cached_property is acceptable, _singledispatchmethod_get caching can always be implemented. For my example, its time is 7.2 µs, to sum up:

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