ACTIVITY SUMMARY (2021-08-06 - 2021-08-13)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7393 ( -4)
closed 49249 (+60)
total 56642 (+56)
Open issues
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
On Fri, Aug 13, 2021 at 11:29 AM Guido van Rossum wrote:
> If these weren't part of the stable ABI, I'd choose (E).
They aren't in the stable ABI (or limited API). Instead, they are
part of the broader public API (declared in Include/cpython/code.h,
along with "struct PyCodeObject" and others).
In 3.11 we're changing a lot of details about code objects. Part of this is
the "Faster CPython" work, part of it is other things (e.g. PEP 657 -- Fine
Grained Error Locations in Tracebacks).
As a result, the set of fields of the code object is changing. This is
fine, the structure is part of the
I'm a major consumer of these APIs as part of some commercial projects
(unfortunately I can't discuss too much further) but we find it worth the
effort of keeping up with CPython internal changes to continue using them.
Option D seems like the best option from my point of view; any user would
On 8/13/2021 1:24 PM, Guido van Rossum wrote:
In 3.11 we're changing a lot of details about code objects. Part of this
is the "Faster CPython" work, part of it is other things (e.g. PEP 657
-- Fine Grained Error Locations in Tracebacks).
As a result, the set of fields of the code object is
On 8/13/2021 8:45 PM, Guido van Rossum wrote:
Now, backwards compatibility is still nothing to sneeze at, but at least
we don't have to hem and haw about ABI compatibility.
If back compatibility were our sacred prime directive, then we would not
(or should not) have changed code objects in
On Fri, Aug 13, 2021 at 11:17 AM Terry Reedy 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
>
