Invoking 'help(...)' unexpectedly includes name of internal wrapper function.

[jayaddison]

Bug report

Bug description:

Attempting to retrieve documentation for the urlsplit function mostly works as expected, but the first line is confusing and appears to originate from a caching wrapper applied to the function (not relevant to usage documentation).

Python 3.12.4 (main, Jul 15 2024, 12:17:32) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.parse import urlsplit
>>> help(urlsplit)

Help on _lru_cache_wrapper in module urllib.parse:

urlsplit(url, scheme='', allow_fragments=True)
...

Note: there is some existing mention of this (help and the interaction with the @lru_cache wrapper) in #88169 - if my report is a dup/invalid, please feel free to close this.

CPython versions tested on:

3.12

Operating systems tested on:

Linux

Edit: fixup: add missing statement from interpreter session.

Linked PRs

• gh-122129: Improve support of method descriptors and wrappers in the help title #122157

[picnixz]

It appears there is an issue with the C implementation:

C implementation

Python 3.12.2 (main, Mar 19 2024, 10:37:03) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import functools
>>> @functools.lru_cache()
... def foo(x): pass
...
>>> help(foo)
Help on _lru_cache_wrapper in module __main__:

foo(x)

Python implementation

Python 3.12.2 (main, Mar 19 2024, 10:37:03) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['_functools'] = None
>>> del sys.modules['functools']
>>> import functools
>>> @functools.lru_cache()
... def foo(x): pass
...
>>> help(foo)
Help on function foo in module __main__:

foo(x)

[picnixz]

@sobolevn You recently had similar observations with help on classes I think, so what do you think we should do?

[serhiy-storchaka]

This is because inspect.isfunction(urlsplit) returns False for the C implementation. And it is right, it is not a Python function.

pydoc.describe() returns "function {name}" for Python functions, "built-in function {name}" for built-in functions, "method {name}" for methods, etc. For unknown types it returns the type name, and this is not bad options for classmethod and staticmethod.

_lru_cache_wrapper is one of few (or only) standard callable types that are not known by pydoc.describe() and have no self-describing type name. Since inspect.isroutine() returns True for it, it is recognized as a callable, therefore pydoc shows its signature and docstring as for functions.

We could add a special case for routines in pydoc.describe(), but we want to handle also classmethod and staticmethod and other callables with nice type name.

[picnixz]

It seems that we need to special-case pydoc but I don't know whether it's worth the effort =/

By the way, do you think we should categorize this one as a feature or a bug? (or just close it for now? I can investigate how much effort it would require though)

[serhiy-storchaka]

I think this is rather a feature request. I mean, it would be nice to backport this change, and it looks harmless, but this is not critical.

[jayaddison]

Thank you @serhiy-storchaka!