(context) > Guido van Rossum schrieb am 13.08.21 um 19:24: > > 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 internal API anyway. > > > > But there's a problem with two public API functions, PyCode_New() and > > PyCode_NewWithPosArgs(). As we have them in the main (3.11) branch, their > > signatures are incompatible with previous versions, and they have to be > > since the set of values needed to create a code object is different. (The > > types.CodeType constructor signature is also changed, and so is its > > replace() method, but these aren't part of any stable API). > > > > Unfortunately, PyCode_New() and PyCode_NewWithPosArgs() are part of the > PEP > > 387 stable ABI. What should we do? > > > > A. We could deprecate them, keep (restore) their old signatures, and > create > > crippled code objects (no exception table, no endline/column tables, > > qualname defaults to name). > > > > B. We could deprecate them, restore the old signatures, and always raise > an > > error when they are called. > > > > C. We could just delete them. > > > > D. We could keep them, with modified signatures, and to heck with ABI > > compatibility for these two. > > > > E. We could get rid of PyCode_NewWithPosArgs(), update PyCode() to add > the > > posonlyargcount (which is the only difference between the two), and d*mn > > the torpedoes. > > > > F. Like (E), but keep PyCode_NewWithPosArgs() as an alias for > PyCode_New() > > (and deprecate it). > > > > If these weren't part of the stable ABI, I'd choose (E). [...] >
On Tue, Aug 31, 2021 at 7:07 PM Stefan Behnel <stefan...@behnel.de> wrote: > I also vote for (E). The creation of a code object is tied to interpreter > internals and thus shouldn't be (or have been) declared stable. > I think you're one of the few people who call those functions, and if even you think it's okay to break backward compatibility here, I think we should just talk to the SC to be absolved of having these two in the stable ABI. (Petr, do you agree? Without your backing I don't feel comfortable even asking for this.) > I think the only problem with that argument is that code objects are > required for frames. You could argue the same way about frames, but then > it > becomes really tricky to, you know, create frames for non-Python code. > Note there's nothing in the stable ABI to create frames. There are only functions to *get* an existing frame, to inspect a frame, and to eval it. In any case even if there was a stable ABI function to create a frame from a code object, one could argue that it's sufficient to be able to get an existing code object from e.g. a function object. > Since we're discussing this in the context of PEP 657, I wonder if there's > a better way to create tracebacks from C code, other than creating fake > frames with fake code objects. > > Cython uses code objects and frames for the following use cases: > > - tracing generated C code at the Python syntax level > - profiling C-implemented functions > - tracebacks for C code > > Having a way to do these three efficiently (i.e. with close to zero > runtime > overhead) without having to reach into internals of the interpreter state, > code objects and frames, would be nice. > > Failing that, I'm ok with declaring the relevant structs and C-API > functions non-stable and letting Cython use them as such, as we always did. > I think others have answered this already -- in any case it's not the immediate subject of this thread, and I don't have a strong opinion on it. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/Z6VSLFMAHYBETSYEYGG4K7EA7DNW3L42/ Code of Conduct: http://python.org/psf/codeofconduct/
