On 04. 02. 22 15:23, Stefan Behnel wrote:
> Petr Viktorin schrieb am 03.02.22 um 13:47:
>> On 02. 02. 22 11:50, Stefan Behnel wrote:
>>> Maybe we should advertise the two modes more. And make sure that both
>>> work. There are certainly issues with the current state of the
>>> "limited API" implementation, but that just needs work and testing.
>> I wonder if it can it be renamed? "Limited API" has a specific meaning
>> since PEP 384, and using it for the public API is adding to the
>> general confusion in this area :(
> I was more referring to it as an *existing* compilation mode of Cython
> that avoids the usage of CPython implementation details. The fact that
> the implementation is incomplete just means that we spill over into
> non-limited API code when no limited API is available for a certain
> feature. That will usually be public API code, unless that is really not
> available either.
> One recent example is the new error locations in tracebacks, where PEP
> 657 explicitly lists the new "co_positions" field in code objects as an
> implementation detail of CPython. If we want to implement this in
> Cython, then there is no other way than to copy these implementation
> details pretty verbatimly from CPython and to depend on them.
> In this specific case, we're lucky that this can be considered an
> entirely optional feature that we can separately disable when users
> request "public API" mode (let's call it that). Not sure if that's what
> users want, though.
Should there be a getter/setter for co_positions?
I'm unfortunately not aware of what Cython needs from code objects, but
it might be good to extend the API here.
Python-Dev mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/XK4DMU7I35TKXYJRYQE4RGMLNNBPDTYN/
Code of Conduct: http://python.org/psf/codeofconduct/