Support text_signature and autogenerated text signature for #[new]
#2866
Labels
Comments
bors bot
added a commit
that referenced
this issue
Jan 27, 2023
2904: refactor docstring generation code r=mejrs a=davidhewitt As a first step towards #2866 this is a tweak to the macro code which generates Python docstrings. This PR refactors the behaviour so that instead of always creating a `concat!` expression to generate a nul-terminated string, this will only happen if a Rust 1.54+ macro doc is present (e.g. `#[doc = include_str!(...)]`). The default case now just collects all the `#[doc]` attributes into a single string. This should make it easier to factor out the `text_signature` formatting, and avoids wasting compile time invoking the `concat!` macro when not necessary. 2921: Check to see if object is `None` before traversing r=davidhewitt a=neachdainn Closes #2915 When using the C API directly, the intended way to call `visitproc` is via the `Py_VISIT` macro, which checks to see that the provided pointer is not null before passing it along to `visitproc`. Because PyO3 isn't using the macro, it needs to manually check that the pointer isn't null. Without this check, calling `visit.call(&obj)` where `let obj = None;` will segfault. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com> Co-authored-by: Nate Kent <nate@nkent.net>
bors bot
added a commit
that referenced
this issue
Feb 13, 2023
2948: don't parse doc attributes unnecessarily r=davidhewitt a=davidhewitt While working on #2866 I found that for all `#[pymethods]` we process the `#[doc]` attributes and build a Python docstring. However we don't always emit this doc - e.g. for class attributes and `__dunder__` methods. This is just a small adjustment to move the `#[doc]` processing slightly later in the macro code to avoid the wasted work. (It also helps for the #2866 implementation later.) Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
bors bot
added a commit
that referenced
this issue
Apr 19, 2023
2980: support `text_signature` on `#[new]` r=adamreichold a=davidhewitt Closes #2866 This is a breaking change for 0.19.0, because it starts autogenerating `text_signature` for `#[new]`. This could affect runtime behaviour if the user is relying on the class docs at runtime for some reason. Guide & tests all updated accordingly. `#[pyclass(text_signature = "...")]` is deprecated by this PR, however if it's set, it will be used in preference to `#[new]`. (The signature / `text_signature` from `#[new]` will simply be ignored in this case. I figure that when users fix their deprecation warnings by removing `#[pyclass(text_signature = "...")]` then the `#[new]` signatures will start flowing properly, and this is good enough.) Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
bors bot
added a commit
that referenced
this issue
Apr 20, 2023
2980: support `text_signature` on `#[new]` r=adamreichold a=davidhewitt Closes #2866 This is a breaking change for 0.19.0, because it starts autogenerating `text_signature` for `#[new]`. This could affect runtime behaviour if the user is relying on the class docs at runtime for some reason. Guide & tests all updated accordingly. `#[pyclass(text_signature = "...")]` is deprecated by this PR, however if it's set, it will be used in preference to `#[new]`. (The signature / `text_signature` from `#[new]` will simply be ignored in this case. I figure that when users fix their deprecation warnings by removing `#[pyclass(text_signature = "...")]` then the `#[new]` signatures will start flowing properly, and this is good enough.) Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
bors bot
added a commit
that referenced
this issue
May 4, 2023
2980: support `text_signature` on `#[new]` r=adamreichold a=davidhewitt Closes #2866 This is a breaking change for 0.19.0, because it starts autogenerating `text_signature` for `#[new]`. This could affect runtime behaviour if the user is relying on the class docs at runtime for some reason. Guide & tests all updated accordingly. `#[pyclass(text_signature = "...")]` is deprecated by this PR, however if it's set, it will be used in preference to `#[new]`. (The signature / `text_signature` from `#[new]` will simply be ignored in this case. I figure that when users fix their deprecation warnings by removing `#[pyclass(text_signature = "...")]` then the `#[new]` signatures will start flowing properly, and this is good enough.) Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
bors bot
added a commit
that referenced
this issue
May 4, 2023
2980: support `text_signature` on `#[new]` r=adamreichold a=davidhewitt Closes #2866 This is a breaking change for 0.19.0, because it starts autogenerating `text_signature` for `#[new]`. This could affect runtime behaviour if the user is relying on the class docs at runtime for some reason. Guide & tests all updated accordingly. `#[pyclass(text_signature = "...")]` is deprecated by this PR, however if it's set, it will be used in preference to `#[new]`. (The signature / `text_signature` from `#[new]` will simply be ignored in this case. I figure that when users fix their deprecation warnings by removing `#[pyclass(text_signature = "...")]` then the `#[new]` signatures will start flowing properly, and this is good enough.) Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com> Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After #2784 we now support autogenerated
text_signaturefor everything except#[new], which can't have any text signature set (it must be put on the#[pyclass]instead).Using some macro and trait magic we should be able to resolve this; I won't do it for 0.18 but perhaps shortly after if nobody else wants to pick this up first (in which case I can point you in the right direction for the implementation).
The text was updated successfully, but these errors were encountered: