Skip to content
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-115398: Revert PyExpat_CAPI_MAGIC version bump #116411

Merged

Conversation

hartwork
Copy link
Contributor

@hartwork hartwork commented Mar 6, 2024

This reverts part of commit eda2963 from #116301 because it is both hurting and unnecessary, #115623 (comment) explains in detail why.

CC @encukou @gpshead @serhiy-storchaka (alphabetical order)

PS: Could someone add label skip-news for me please, I lack permissions to. Thanks! 🙏

@AlexWaygood AlexWaygood changed the title Revert PyExpat_CAPI_MAGIC version bump gh-115398: Revert PyExpat_CAPI_MAGIC version bump Mar 6, 2024
@gpshead gpshead merged commit 8a8e920 into python:main Mar 6, 2024
36 checks passed
adorilson pushed a commit to adorilson/cpython that referenced this pull request Mar 25, 2024
…16411)

Revert "pythongh-115398: Increment PyExpat_CAPI_MAGIC for SetReparseDeferralEnabled addition (pythonGH-116301)"

This reverts part of commit eda2963.  Why? this comment buried in an earlier code review explains:

I checked again how that value is used in practice, it's here:

https://github.com/python/cpython/blob/0c80da4c14d904a367968955544dd6ae58c8101c/Modules/_elementtree.c#L4363-L4372

Based on that code my understanding is that loading bigger structs from the future is considered okay unless `PyExpat_CAPI_MAGIC` differs, which implies that (1) magic needs to stay the same to support loading the future from the past and (2) that `PyExpat_CAPI_MAGIC` should only ever change for changes that do not increase size (but keep it constant).

To summarize, that supports your argument.
I checked branches 3.8, 3.9, 3.10, 3.11, 3.12 now and they all have the same comparison code there so reverting that magic string bump will support seamless backporting.
diegorusso pushed a commit to diegorusso/cpython that referenced this pull request Apr 17, 2024
…16411)

Revert "pythongh-115398: Increment PyExpat_CAPI_MAGIC for SetReparseDeferralEnabled addition (pythonGH-116301)"

This reverts part of commit eda2963.  Why? this comment buried in an earlier code review explains:

I checked again how that value is used in practice, it's here:

https://github.com/python/cpython/blob/0c80da4c14d904a367968955544dd6ae58c8101c/Modules/_elementtree.c#L4363-L4372

Based on that code my understanding is that loading bigger structs from the future is considered okay unless `PyExpat_CAPI_MAGIC` differs, which implies that (1) magic needs to stay the same to support loading the future from the past and (2) that `PyExpat_CAPI_MAGIC` should only ever change for changes that do not increase size (but keep it constant).

To summarize, that supports your argument.
I checked branches 3.8, 3.9, 3.10, 3.11, 3.12 now and they all have the same comparison code there so reverting that magic string bump will support seamless backporting.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants