Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jayaddison opened this issue Jul 22, 2024 · 6 comments
Closed
Labels
3.14 new features, bugs and security fixes type-feature A feature request or enhancement

Comments

@jayaddison
Copy link

jayaddison commented Jul 22, 2024

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

@jayaddison jayaddison added the type-bug An unexpected behavior, bug, or error label Jul 22, 2024
@picnixz
Copy link
Contributor

picnixz commented Jul 22, 2024

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
Copy link
Contributor

picnixz commented Jul 22, 2024

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

@serhiy-storchaka
Copy link
Member

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
Copy link
Contributor

picnixz commented 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)

serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this issue Jul 23, 2024
@serhiy-storchaka serhiy-storchaka added type-feature A feature request or enhancement 3.14 new features, bugs and security fixes and removed type-bug An unexpected behavior, bug, or error labels Jul 23, 2024
@serhiy-storchaka
Copy link
Member

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
Copy link
Author

Thank you @serhiy-storchaka!

nohlson pushed a commit to nohlson/cpython that referenced this issue Jul 24, 2024
nohlson pushed a commit to nohlson/cpython that referenced this issue Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.14 new features, bugs and security fixes type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

3 participants