Mark Shannon <m...@hotpy.org> added the comment:
IMO those failures are bugs in the projects listed not in CPython. Relying on the exact meaning, or even the existence of an undocumented field of a C struct is not, nor ever has been, safe. The user of the field is assuming a meaning that is not known to the developers of the library/application, so there is no way for them to preserve that meaning. This is not specific to CPython, but applies to any C API. 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. However, it has no such meaning. It is an internal performance optimization to avoid checking both `tstate->c_tracefunc` and `tstate->c_profilefunc`. It is `tstate->tracing` that determines whether tracing is active or not. I propose adding back `tstate->use_tracing` as a copy of `tstate->cframe->us_tracing`. Any writes to `tstate->use_tracing` will be ignored, but any code that also sets `tstate->tracing`, as the Cython code does, will work correctly. Any code that reads `tstate->use_tracing` will work correctly. I'm minded to prefix all the names of all fields in all C structs that happen to be included by Python.h with "if_you_use_this_then_we_will_break_your_code_in_some_way_that_will_ruin_your_reputation_as_a_library_developer__maybe_not_tomorrow_maybe_not_next_year_but_someday" Although that might prove tricky with a 80 character line limit :) My attempts to avoid this happening again next year, and the year after that, and... https://bugs.python.org/issue45247 https://github.com/cython/cython/issues/4382 ---------- _______________________________________ 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
