On 16Nov2016 1618, Ned Batchelder wrote: > When I added Python 3.6 support to coverage.py, I posted a Mac wheel to > PyPI: https://pypi.python.org/pypi/coverage/ That wheel was built > against 3.6a3, the latest version at the time. When I use it now on > 3.6b3, it doesn't work right. The reason is that the co_firstlineno > field in PyCodeObject moved in September, as part of the PEP 523 work: > https://github.com/python/cpython/commit/f1e6d88b3ca2b56d51d87b6b38ea1870c5d9490c > > The docs say that PyCodeObject can change at any time, but I don't see > why the field had to move in the first place. Was this needed? IIRC, by reordering the fields we saved enough memory in padding that the new field did not take up any extra space (assuming 32-bit int and 64-bit pointers). > Am I doing the wrong thing by using PyCodeObject fields directly in the > coverage.py C trace function? It seems like this was an unnecessary > breaking change, even if it is a non-guaranteed interface. I suspect the "wrong thing" here is expecting to not see any changes between alpha/beta versions. It certainly should not change within 3.6.x, so your wheel build will be fine, but changing during the prerelease versions is a possibility for anything not in the limited ABI. Cheers, Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4