-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
GH-78724: Initialize struct.Struct in __new__ #94532
Conversation
🤖 New build scheduled with the buildbot fleet by @kumaraditya303 for commit a74cdbb 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
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. I'm wondering if moving initialization from __init__
to __new__
can cause some user-facing backwards compatibility, say, wrt subclassing or something. I asked for more eyes on this.
Apologies for the silence; I'll get to this by the end of this weekend. |
LGTM too. To be on the safe side, I'd recommend not backporting this to 3.10, though it seems fine to backport to 3.11 if @pablogsal agrees. The bugs being fixed seem to be of the self-inflicted "well don't do that then" variety, so while it's definitely nice to have them fixed, it seems unlikely that they'll be blocking any real users of |
Yes, it can. This is fine, on Python 3.10: >>> import struct
>>> class Bob(struct.Struct):
... def __init__(self, format):
... super().__init__(format)
...
>>> b = Bob("!f")
>>> b.pack(2.3)
b'@\x1333' But it breaks on this branch: >>> import struct
>>> class Bob(struct.Struct):
... def __init__(self, format):
... super().__init__(format)
...
>>> b = Bob("!f")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in __init__
TypeError: object.__init__() takes exactly one argument (the instance to initialize) I'm finding it hard to imagine why anyone would be subclassing |
I think is ok to backport to 3.11 👍 Not sure if it makes sense to mention the subclassing incompatibility in the what's new, though. |
@kumaraditya303 Apologies, Kumar; I'm having second thoughts here. While common sense says that no-one will be subclassing Can you think of any ways that we could fix these bugs without the backward compatibility breakage? |
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.
On balance, the backwards compatibility change seems like something we should avoid if possible.
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 |
Thanks for the reviews!
I have made it backwards compatible by adding I have made the requested changes; please review again @mdickinson @ambv |
Thanks for the review, I'll make the changes by next weekend. |
cc @mdickinson I have made the changes, I removed the code duplication and it is now only for 3.12+. |
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. I'll do a buildbot run, to be on the safe side.
🤖 New build scheduled with the buildbot fleet by @mdickinson for commit d7ce7d8 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
The buildbots look happy. There are still three checks pending as of writing, but enough checks have passed to satisfy me. I'll merge now, but continue to watch those remaining three bots. |
So I just hit this while trying to upgrade to 3.12. While subclassing works, subclasses MUST now match the same signature for from struct import Struct
class FloatStruct(Struct):
def __init__(self):
super().__init__('f')
f = FloatStruct() gives Traceback (most recent call last):
File "/Users/rmay/test.py", line 7, in <module>
f = FloatStruct()
^^^^^^^^^^^^^
TypeError: Struct() missing required argument 'format' (pos 1) My actual use case was passing additional arguments, but either way fails. I'm not here to necessarily vouch for why our implementation uses that, but it was seriously confusing not understanding why |
…truct.Struct. (pythonGH-112424) Revert commit c8c0afc (PR pythonGH-94532), which moved `struct.Struct` initialisation from `Struct.__init__` to `Struct.__new__`. This caused issues with code in the wild that subclasses `struct.Struct`.. (cherry picked from commit 9fe6034) Co-authored-by: Mark Dickinson <dickinsm@gmail.com>
…Struct (GH-112424) (#112426) * [3.12] gh-112358: Fix Python 3.12 regression with subclassing struct.Struct. (GH-112424) Revert commit c8c0afc (PR GH-94532), which moved `struct.Struct` initialisation from `Struct.__init__` to `Struct.__new__`. This caused issues with code in the wild that subclasses `struct.Struct`.. (cherry picked from commit 9fe6034) Co-authored-by: Mark Dickinson <dickinsm@gmail.com> * Remove unrelated test
…truct. (python#112424) Revert commit c8c0afc (PR python#94532), which moved `struct.Struct` initialisation from `Struct.__init__` to `Struct.__new__`. This caused issues with code in the wild that subclasses `struct.Struct`.
…truct. (python#112424) Revert commit c8c0afc (PR python#94532), which moved `struct.Struct` initialisation from `Struct.__init__` to `Struct.__new__`. This caused issues with code in the wild that subclasses `struct.Struct`.
Closes #75960
Closes #78724