Home Original page

gh-115398: Increment PyExpat_CAPI_MAGIC for SetReparseDeferralEnabled addition by gpshead · Pull Request #116301 · python/cpython

added 2 commits

March 4, 2024 10:01

@gpshead gpshead marked this pull request as ready for review

March 4, 2024 10:14

This was referenced

Mar 4, 2024

woodruffw pushed a commit to woodruffw-forks/cpython that referenced this pull request

Mar 4, 2024 
…nabled addition (pythonGH-116301)

* Increment PyExpat_CAPI_MAGIC due to SetReparseDeferralEnabled addition.

This is a followup to git commit
6a95676 from Github PR python#115623.

* RESTify news API list.

hartwork added a commit to hartwork/cpython that referenced this pull request

Mar 6, 2024

@hartwork

gpshead pushed a commit that referenced this pull request

Mar 6, 2024 
Revert "gh-115398: Increment PyExpat_CAPI_MAGIC for SetReparseDeferralEnabled addition (GH-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.

@gpshead gpshead deleted the fixup/gh115398/details branch

March 6, 2024 17:58

adorilson pushed a commit to adorilson/cpython that referenced this pull request

Mar 25, 2024 
…nabled addition (pythonGH-116301)

* Increment PyExpat_CAPI_MAGIC due to SetReparseDeferralEnabled addition.

This is a followup to git commit
6a95676 from Github PR python#115623.

* RESTify news API list.

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 
…nabled addition (pythonGH-116301)

* Increment PyExpat_CAPI_MAGIC due to SetReparseDeferralEnabled addition.

This is a followup to git commit
6a95676 from Github PR python#115623.

* RESTify news API list.

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.