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

Accommodate Sphinx option by changing docstring return type of "integer" to "int". #100989

Open
timoludwig opened this issue Jan 12, 2023 · 2 comments
Labels
type-bug An unexpected behavior, bug, or error

Comments

@timoludwig
Copy link

timoludwig commented Jan 12, 2023

Bug report

When collections.deque is subclassed and the resulting class is documented with Sphinx using the option :inherited-members:, the following error appears:

WARNING: py:class reference target not found: integer -- return number of occurrences of value

I assume this is because the PyDoc_STRVAR docstring of the C-implementation is not compliant to PEP-7 as required in PyDoc_STRVAR:

PyDoc_STRVAR(count_doc,
"D.count(value) -> integer -- return number of occurrences of value");

And everything after -> is interpreted as type hint.

This can be reproduced with e.g. a python module sub_deque.py:

class SubDeque(deque):
    pass

and a documenation file docs/src/sub_deque.rst:

.. automodule:: sub_deque
   :inherited-members:

which is then built with Sphinx: sphinx-build -W docs/src docs/dist.

I'd be happy to provide a patch for this myself if you feel this issue should be fixed.

Your environment

  • CPython versions tested on: 3.7 - 3.11
  • Operating system and architecture: Arch Linux & Ubuntu

Linked PRs

@timoludwig timoludwig added the type-bug An unexpected behavior, bug, or error label Jan 12, 2023
timoludwig added a commit to timoludwig/cpython that referenced this issue Jan 12, 2023
timoludwig added a commit to timoludwig/cpython that referenced this issue Jan 12, 2023
@rhettinger
Copy link
Contributor

You can change "integer" to "int" if you like. The other changes look gratuitous.

Also, PEP 7 predates modern type annotations. Doc strings are allowed to put any text as the return type as long as it is interpretable by a human. It is unfortunate that Sphinx is assuming otherwise. How would it handle user defined types or types defined in type comments?

@rhettinger rhettinger changed the title Docstrings of collections.deque not compliant to PEP-7 Accommodate Sphinx option by changing docstring return type of "integer" to "int". Jan 12, 2023
@timoludwig
Copy link
Author

Ok, thanks for your feedback!

You can change "integer" to "int" if you like. The other changes look gratuitous.

Still, changing it to D.count(value) -> int -- return number of occurrences of value would just cause Sphinx to literally search for the type int -- return number of occurrences of value which it wouldn't find either. Are you fine with including the new line after the return type? So D.count(value) -> int\n ...? Most of the other modules seem to follow that convention:

"_ncallbacks() -> int\n\

"acquire(blocking=True, timeout=-1) -> bool\n\

"get_default_domain() -> str\n\

Although to be fair, I also found quite a few other modules which use an inconsistent format, e.g.

"time() -> floating point number\n\

which I would change to time() -> float to match the correct type and allow the cross-referencing between documentations.

Also, PEP 7 predates modern type annotations.

Are there better options to annotate types in C modules? If so, I think it should be mentioned in the docs of PyDoc_STRVAR...

How would it handle user defined types or types defined in type comments?

User defined types are usually documented in the project that Sphinx is invoked in, and thus it'll find the reference to the custom type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants