If creating a fake frame is a common use case, we can maybe write a public C API for that. For example, I saw parser injecting frames to show the file name and line number of the parsed file in the traceback.
Victor On Wed, Sep 1, 2021 at 4:07 AM Stefan Behnel <stefan...@behnel.de> wrote: > > 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). [...] > > 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 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. > > 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. > > Stefan > > _______________________________________________ > 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/XYNNMH57O7CYWHYKTD3ELZTM3B4M53HL/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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/QYDIQ5SS3FQCTDBBZ3JTI643KV4F6TNY/ Code of Conduct: http://python.org/psf/codeofconduct/
