[...]
A cloning-with-replacement API that accepted the base code object and the "safe to modify" fields could be a good complement to the API deprecation proposal.
Yes (I forgot to mention that).
Moving actual "from scratch" code object creation behind the Py_BUILD_CORE guard with an underscore prefix on the name would also make sense, since it defines a key piece of the compiler/interpreter boundary.
Yeah, we have _PyCode_New() for that.
Cheers,
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.
That's 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.