On Fri, Aug 13, 2021 at 11:17 AM Terry Reedy <tjreedy@udel.edu> wrote:
On 8/13/2021 1:24 PM, Guido van Rossum wrote:
[...]
> Unfortunately, PyCode_New() and PyCode_NewWithPosArgs() are part of the
> PEP 387 stable ABI. What should we do?

PEP 387 is Backwards Compatibility Policy
https://www.python.org/dev/peps/pep-0387/
Did you mean PEP 384 -- Defining a Stable ABI
https://www.python.org/dev/peps/pep-0384/

Aargh! You're right! I misremembered the PEP number (and didn't double check) and when Pablo said we were "constrained by PEP 387" I assumed he meant the stable ABI. Sorry for the goof-up.

Now, backwards compatibility is still nothing to sneeze at, but at least we don't have to hem and haw about ABI compatibility.

The question then is, can we break (source) backwards compatibility for these two functions, because in practice code objects have been unstable? Or do we need to go the deprecation route here using (A) or (B) for two releases. Presumably we could combine these two so that it reports a warning when called, and if the warning has been configured to be replaced with an error it will raise that.

Thanks also to Eric for pointing out the same thing. (I should probably have waited to discuss this with him before posting. Sorry again.)


On Fri, Aug 13, 2021 at 3:39 PM Jim J. Jewett <jimjjewett@gmail.com> wrote:
How badly would the code objects be crippled?

>(no exception table, no endline/column tables,
> qualname defaults to name)

That sounds like it would be a pain for debugging, but might still work for source/code that hadn't actually changed and was just being re-compiled and run (possibly with the caveat that the data needs to be clean enough to avoid exceptions).

Yeah, I would be okay with faking it for endline/column tables and qualname, but I balk at the exception table -- this is used for the new 3.11 concept "zero cost exception handling" where a try block doesn't require any setup (the opcode for this has gone away). Too much valid code catches exceptions (e.g. KeyError) to trust that this will mostly do the right thing.
 
Since that is a common use case, and one where there is a good reason not to make any source-level changes, it would be good to keep compatibility for that minimal level.

I'm actually not sure what use case you're talking about.

--
--Guido van Rossum (python.org/~guido)