> Should there be a getter/setter for co_positions? We consider the representation of co_postions private, so we don't want (for now) to ad getters/setters. If you want to get the position of a instruction, you can use PyCode_Addr2Location
On Wed, 9 Feb 2022 at 16:22, Petr Viktorin <encu...@gmail.com> wrote: > 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. > > > > https://www.python.org/dev/peps/pep-0657/ > > > > 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 -- 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/XK4DMU7I35TKXYJRYQE4RGMLNNBPDTYN/ > 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/N537EIZR4KIR6Z7G3J2PTYC26DPH3YNC/ Code of Conduct: http://python.org/psf/codeofconduct/
