You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Invoking 'help(...)' unexpectedly includes name of internal wrapper function. #122129
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).
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.
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()
... deffoo(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()
... deffoo(x): pass
...
>>> help(foo)
Help on function foo in module __main__:
foo(x)
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.
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)
Activity
picnixz commentedon Jul 22, 2024
It appears there is an issue with the C implementation:
C implementation
Python implementation
picnixz commentedon Jul 22, 2024
@sobolevn You recently had similar observations with
helpon classes I think, so what do you think we should do?serhiy-storchaka commentedon Jul 23, 2024
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 forclassmethodandstaticmethod._lru_cache_wrapperis one of few (or only) standard callable types that are not known bypydoc.describe()and have no self-describing type name. Sinceinspect.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 alsoclassmethodandstaticmethodand other callables with nice type name.picnixz commentedon Jul 23, 2024
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)
pythongh-122129: Improve support of method descriptors and wrappers i…
serhiy-storchaka commentedon Jul 23, 2024
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.
gh-122129: Improve support of method descriptors and wrappers in the …
jayaddison commentedon Jul 23, 2024
Thank you @serhiy-storchaka!
pythongh-122129: Improve support of method descriptors and wrappers i…
pythongh-122129: Improve support of method descriptors and wrappers i…