Stefan Behnel added the comment:
> what's the migration path for C API users that were relying on that struct
> field?
Depends on how you use it, I guess. In many cases (at least for Cython and
likely some other low-level tools), it could be as simple as
#if PY_VERSION_HEX < 0x030400B2
// set "f_tstate" here
#endif
My guess is that some (most?) code that sets this field only does so because
CPython previously depended on it being set. (Stackless comes to mind, not sure
if that's supposed to work with 3.x...)
Read access is an entirely different thing, though. No idea what other tools
might be using it for. I'm sure there are debugging/tracing tools out there
that make use of the frame internals. Would it be correct for them to just use
the current thread state instead? E.g. from a signal handler that analysis the
current threads?
On a quick look through Ohloh's code search I only found a couple of other
occurrences outside of CPython so far.
http://code.ohloh.net/search?s=%22f_tstate%22&fe=c&filterChecked=true
Disclaimer: it's easy to fix for me with the above conditional, so I won't
argue much about keeping up compatibility here. I'm merely raising the issue
because there is evidently code that this change breaks.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
