-
Notifications
You must be signed in to change notification settings - Fork 778
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
support text_signature
on #[new]
#2980
Conversation
92a88fa
to
3c9fbe7
Compare
@adamreichold I've just rebased this, and I think (assuming CI passes) it might be ready to merge. |
3c9fbe7
to
b0e7dd8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Single nit. Please feel free to merge after resolving this.
b0e7dd8
to
8acb224
Compare
bors r=adamreichold |
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>
Build failed: |
bors retry |
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>
Build failed: |
The nightly warning on The test failure in |
Actually, I cannot reproduce this on |
8acb224
to
8bd17f0
Compare
Rebased; let's hope things are working again now. Sorry for the gap! bors r=adamreichold |
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>
Build failed: |
I think
still applies. |
Sadly, I cannot reproduce the issue locally even using Python 3.7, neither via pyenv (which is 3.7.16 as in GitHub actions) nor using indygreg's standalone builds which stopped at 3.7.9. |
Sorry, I am an idiot for trying this on the |
…on 3.10 as we do not support it.
I think this is due to us not being able to set bors r+ |
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>
Build failed: |
bors retry |
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
Thanks 😅 |
2981: Remove 0.17 deprecations r=adamreichold,davidhewitt a=davidhewitt Since #2980 starts a breaking change for 0.19, let's also clean up all 0.17's deprecations. I've removed `Python::acquire_gil` in its own commit, as that was a reasonably chunky removal. Co-authored-by: Adam Reichold <adam.reichold@t-online.de> Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
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.)