Docstrings for `#[new]` method implementations
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 16.2k
- Forks
- 1k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 66
Description
Discussed in https://github.com/PyO3/pyo3/discussions/4280
Originally posted by djc June 23, 2024
When I write a docstring on a #[new] fn new() method in a #[pymethods] impl block, I would expect this to show up in the help() output for the type. Instead, the help() output seems to end up with a default docstring:
| Static methods defined here:
|
| __new__(*args, **kwargs)
| Create and return a new object. See help(type) for accurate signature.
Is there no way in Python's data model to enable a specific help string for this? The docstring for the type ends up making it into the output sort of next to the constructor type signature, so I guess I could use that. Just seems surprising.
I believe that it should be possible to do something similar to what we already do with the text_signature for #[new] to lift the rest of the documentation onto the class. But this needs some experimentation.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the discussion at https://github.com/PyO3/pyo3/discussions/4280 and the existing handling of text_signature for #[new]. Experiment with how documentation from a #[new] method in a #[pymethods] impl appears in Python help() output; done means the method's docstring is surfaced appropriately without regressing the type or constructor signature.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, rust
- Domain
- api
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100