Stefan Behnel <stefan...@behnel.de> added the comment:

> The code in the examples given above are using `tstate->use_tracing` assuming 
> that its meaning is to determine whether tracing is turned on or not.

No, actually not. It is using the field in the same way as CPython, simply 
because most of this code was originally copied from CPython, and we also 
copied the optimisation of avoiding to check the other fields (for the obvious 
reason of being an optimisation).


> I propose adding back `tstate->use_tracing` as a copy of 
> `tstate->cframe->us_tracing`.

Cython 0.29.24 has already been adapted to this change and will use the new 
field in CPython 3.10b1+.


> Any code that reads `tstate->use_tracing` will work correctly.

Any code that reads and /writes/ the field would probably also continue to work 
correctly, which is what older Cython versions did.


> if_you_use_this_then_we_will_break_your_code_in_some_way_that_will_ruin_your_reputation_as_a_library_developer…

The thing is, new APIs can only be added to new CPython releases. Supporting 
features in older CPython versions (currently 2.7+) means that we always *have 
to* use the existing fields, and can only switch to new APIs by duplicating 
code based on a PY_VERSION_HEX preprocessor check. Even if a new low-latency 
profiling API was added in CPython 3.11, we'd have to wait until there is at 
least an alpha release that has it before enabling this code switch.

And if the new API proves to be slower, we may end up keeping the old code 
around and adding a C compile-time configuration option for users to enable (or 
disable) its use. Cython has lots of those these days, mostly to support the 
different C-API capabilities of different Python implementations, e.g. to take 
advantage of the PyLong or PyUnicode internals if available, and use generic 
C-API calls if not.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue43760>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to