On 17. 08. 21 12:00, Łukasz Langa wrote:
Hi everybody,
I'd like to revive this thread as I feel like we have to do something
here but some consensus is needed first.
To recap, the current state of things is as follows:
- *in March 2000* (d724b23420f) Christian Tismer contributed the
"trashcan" patch that added Py_TRASHCAN_SAFE_BEGIN
and Py_TRASHCAN_SAFE_END macros which allow destroying nested objects
non-recursively.
- *in May 2019* (GH-11841 of BPO-35983) Antoine Pitrou merged a change
by Jeroen Demeyer which made Py_TRASHCAN_SAFE_BEGIN/END
(unintentionally?) backwards incompatible; this was released in Python
3.8.0.
- by the way, GH-11841 introduced a new pair of macros (because they
have different signatures) called simply Py_TRASHCAN_BEGIN and
Py_TRASHCAN_END.
- by that time there was already a follow-up PR open (GH-12607) to
improve backwards compatibility of the macros, as well as introduce
tests for them; this was never merged.
- *in Feb 2020* (0fa4f43db08) Victor Stinner removed the trashcan
mechanism from the limited C API (note: not ABI, those are macros) since
it accesses fields of structs not exposed in the limited C API; this was
released in Python 3.9.0.
- *in May 2020* Irit noticed that the backwards incompatibility
(BPO-40608) causes segfaults for C API code that worked fine with Python
3.7. Using the new macros requires code changes but doesn't crash.
Now, there are a couple of things we can do here:
*Option 1*: Finish GH-12607 to fix the old macros, keeping in mind this
will restore compatibility lost with Python 3.8 - 3.10 only for users of
3.11+
*Option 2*: Review and merge GH-20104 that reverts the macro changes
that make old client code segfault -- unclear what else this needs and
again, that would only fix it for users of 3.11+
*Option 3*: Abandon GH-12607 and GH-20104, instead declaring the old
macros deprecated for 3.11 and remove them in 3.13
I personally agree with Irit, voting +1 for Option 3 since the old
macros were soft-deprecated already by introducing new macros in 3.8,
and more importantly made incompatible with pre-3.8 usage.
+1.
The deprecation should follow PEP 387, which means emitting a warning. I
think a compiler warning is appropriate; that could be done by having
the macro call a deprecated function. Depending on how broken the macros
are, a compiler warning could be backported to older versions.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/KWFX6XX3HMZBQ2BYBVL7G74AIOPWO66Y/
Code of Conduct: http://python.org/psf/codeofconduct/
