-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
autodoc incorrectly displays class methods for builtin types #13188
Comments
This isn't a minimal reproducible example because the report doesn't have the bare minimum code and thus isn't self-contained instead linking to an external repo. But it's a known issue that Sphinx can't extract everything from a CPython C-API because the C implementation doesn't allow for complete introspection. Your can search the repo and Stack Overflow but the usual workaround is to manually declare the needed doc elements in the |
Well, I can create somewhat more minimal one. But it will require at least one builtin type and at least one method on it. A lot of code, anyway.
As it shown above - inspect module can. And builtin help() function too (which uses inspect module capabilities).
There is no documented way to provide introspection capabilities for C extensions. However, it's possible and in my case the gmp module does this properly. The sphinx should utilize that and work correctly just as help() does. There is nothing wrong: help() uses public interfaces from the inspect module.
I.e. not use autodoc at all. In principle, another such "workaround" is using PEP 7-style docstrings (e.g. the gmpy2 package does that). But this will break introspection support. |
I think the signature object should contain "cls" as first parameter, otherwise we don't detect it as a class method. I don't know if help() doesn't just render the signature as is. I suspect we just consider bytes to be "self" and thus we don't know that ir was actually a class method. I'll have a look at it in a few days or so, or just ping me if I forgot. |
No, it shouldn't. This is only a naming convention for pure-Python code.
No, it's correctly determine the method as a class method for a builtin. Then the first argument - properly ignored (not the second one, i.e. bytes).
Well, the pydoc does something like that with all available introspection: >>> inspect.signature(mpz.from_bytes) # how signature looks
<Signature (bytes, byteorder='big', *, signed=False)>
>>> inspect.isbuiltin(mpz.from_bytes)
True
>>> mpz.from_bytes.__self__
<class 'gmp.mpz'>
>>> inspect.isclass(mpz.from_bytes.__self__) # aha, probably it's a class method
True
>>> self = mpz.from_bytes.__self__
>>> name = mpz.from_bytes.__name__
>>> self.__qualname__ + '.' + name == mpz.from_bytes.__qualname__ # second check
True
Well, I'll have to prepare some workaround for the next release, so it's not urgent. I'll provide a smaller reproducer for you and, perhaps, will dig into this if I've found a time. |
I'll be without network access for the next two days so I'll try fixing this in the meantime. |
FTR, I have fixed the issue locally (and found a separate issue at the same time that is not related). I'll push something tomorrow (the issue was that a class method implemented in C is not an instance of classmethod but a class method descriptor... but for static methods that's not the case...) |
Describe the bug
My package has two types. One implemented as pure-Python class and other with CPython C-API. Both have class methods with correct signatures:
As you can see, both correctly displayed by the builtin help(). However, sphinx shows second method like that:
The method miss "classmethod" mark and also the first argument (bytes) - was removed.
How to Reproduce
Sphinx configuration: https://github.com/diofant/python-gmp/tree/e281e2a75a435c1ca52efdf1777ea420ef02ae22/docs
Environment Information
Sphinx extensions
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: