-
-
Notifications
You must be signed in to change notification settings - Fork 30k
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
bpo-43827: Fixed abc conflicts with __init_subclass__ #25385
Conversation
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.
LGTM
Hi @serhiy-storchaka |
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.
This seems in line with what @serhiy-storchaka was trying to do in GH-13700, though I'm not confident that we can consider this to be a backwards-compatible change. Even though _py_abc
has had this same signature for a while, I think most people get this version, not the other one, so it's possible this will break someone passing one of these by keyword. If we're going to change it, it should probably be 3.11+ and not backported.
Also, this needs at least one test. Presumably the MWE detailed in the BPO issue can be refactored into a test.
@@ -0,0 +1 @@ | |||
Fix abc.ABCMeta conflicts with __init_subclass__ |
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.
This is not really enough context for someone to understand what is changing just from reading the changelog. Something more like this would be better:
"All positional-or-keyword parameters to ABCMeta.__new__
are now positional-only to avoid conflicts with keyword arguments to be passed to __init_subclass__
."
I am not super confident that that's the only thing that ABCMeta
's **kwargs
is used for, so if it's used for other stuff, more general wording would be appropriate.
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
I have made the requested changes; please review again |
Thanks for making the requested changes! @pganssle: please review the changes made to this pull request. |
@pganssle can you take a look, please? |
@pganssle are you there? |
Hi @pganssle |
Misc/NEWS.d/next/Library/2021-04-16-17-32-44.bpo-43827.uJaXdP.rst
Outdated
Show resolved
Hide resolved
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.
Thanks, looks good! Unfortunately you'll have to re-sign the CLA under the new (much simpler) process.
Thanks for your changes! We still need the CLA to be signed. |
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.
LGTM.
Hi @JelleZijlstra @serhiy-storchaka Thanks for the review.
|
I'd recommend you set your local git config to the right email address, then squash the commits on this branch and force-push the new commit. |
@JelleZijlstra looks like it didn't help. Should close this pr and create a new one and ping you there? |
Sure, that's worth trying. |
Hi @JelleZijlstra |
https://bugs.python.org/issue43827