GeezerVison

…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.

…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.