> If creating a fake frame is a common use case, we can maybe write a public C API for that.
I don't think we should think on those terms. We certainly don't want to be on a case where yet again we cannot change the internals because we have an official C-API exposed. > For example, I saw parser injecting frames to show the file name and line number of the parsed file in the traceback. You saw "parser" doing that? What is "parser"? Certainly is not the CPython parser because I don't recall that we do any of that. On Wed, 1 Sept 2021 at 17:48, Victor Stinner <vstin...@python.org> wrote: > 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/ >
_______________________________________________ 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/ZLYEFKDWVZIE3LEXF3DPYJO2QJ2BT6KE/ Code of Conduct: http://python.org/psf/codeofconduct/
