I'm late to the thread, and as I read it I see everything I wanted to
say was covered already :)
So just a few clarifications.
The stable ABI is not defined by PEP 384 or PEP 652 or by the header
something is defined in, but by the docs:
- https://docs.python.org/dev/c-api/stable.html
and changes to it are covered in the devguide:
- https://devguide.python.org/c-api/
We have 3 API layers:
1. Internal API, guarded by Py_BUILD_CORE, can break *even in point
releases*. (Py_BUILD_CORE means just that: things like `_PyCode_New` can
only be used safely if you build/embed CPython yourself.)
2. Regular C-API, covered by PEP 387 (breaking changes need deprecation
for 2 releases, or an exception from the SC); `PyCode_New*` is here now
2. Stable ABI, which is hard to change, and thankfully isn't involved here.
I can see that having `.replace()` equivalent in the C API would be
"worth the effort of [its users having to] keeping up with CPython
internal changes" (to quote Patrick).
Looks like we could use something between layers 1 and 2 above for
"high-maintenance" users (like Cython): API that will work for all of
3.11.x, but can freely break for 3.12. I don't think this needs an
explicit API layer, though: just a note in the docs that a new
`PyCode_NewWithAllTheWithBellsAndWhistles` is expected to change in
point releases. But...
Guido:
[struct rather than N arguments] is the
API style that _PyCode_New() uses (thanks to Eric who
IIRC pushed for this and implemented it). You gave me an idea now:
the C equivalent to .replace() could use the same input structure;
one can leave fields NULL that should be copied from the original
unmodified.
From a usability point of view, that's a much better idea than a
function that's expected to change. It would probably also be easier to
implement than an entirely separate public API.
Nick:
P.S. Noting an idea that won't work, in case anyone else reading
the thread was thinking the same thing: a "PyType_FromSpec"
style API won't help here, as the issue is that the compiler is
now doing more work up front and recording that extra info in
the code object for the interpreter to use. There is no way to
synthesise that info if it isn't passed to the constructor, as
it isn't intrinsically recorded in the opcode sequence.
I guess it might be possible to add a flag that says a piece of bytecode
object has exception handling and so it needs an exception table, and
have the old API raise when the flag is on.
It's probably not worth the effort, though.
_______________________________________________
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/T32UC25S3R7MTAKTZRF22ZJ26K6WMFGO/
Code of Conduct: http://python.org/psf/codeofconduct/
