On 01. 09. 21 22:28, Guido van Rossum wrote:
I apologize, I keep making the same mistake.
The PyCode_New[WithPosArgs] functions are *not* in the stable ABI or in
the limited API, so there's no need to petition the SC, nor do I need
Petr's approval.
We may be bound by backwards compatibility for the *cpython* API, but I
think that if Cython is okay if we just break this we should be fine.
Users of the CPython API are expected to recompile for each new version,
and if someone were to be using these functions with the old set of
parameters the compiler would give them an error.
The cpython CPI is still covered by the backwards compatibility policy
(PEP 387). You do need to ask the SC to skip the two-year deprecation
period.
I don't see an issue with the exception being granted, but I do think it
should be rubber-stamped as a project-wide decision.
So let's just choose (E) and d*mn backwards compatibility for these two
functions.
That means:
- Get rid of PyCode_NewWithPosArgs altogether
- PyCode_New becomes unstable (and gets a new posinlyargcount argument)
... but still remains available and documented, just with a note that it
may change in minor versions. Right?
On Wed, Sep 1, 2021 at 11:52 AM Guido van Rossum <gu...@python.org
<mailto:gu...@python.org>> wrote:
(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
<mailto: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 <http://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/>
--
--Guido van Rossum (python.org/~guido <http://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/LYIFIVPSFGS2OFIRKAYKGOAVKJTDNAHD/
Code of Conduct: http://python.org/psf/codeofconduct/
