Message206078
> 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. |
|
Date |
User |
Action |
Args |
2013-12-13 13:34:53 | scoder | set | recipients:
+ scoder, ncoghlan, pitrou, vstinner, asvetlov, adamtj, neologix, Mark.Shannon, rosslagerwall, python-dev, serhiy.storchaka, asuffield |
2013-12-13 13:34:53 | scoder | set | messageid: <1386941693.29.0.344998656345.issue14432@psf.upfronthosting.co.za> |
2013-12-13 13:34:53 | scoder | link | issue14432 messages |
2013-12-13 13:34:52 | scoder | create | |
|