Re: [Python-Dev] Recent changes to PyCodeObject

2016-11-16 Thread Steve Dower
Yeah, we did. That issue had been around since the betas though, it just wasn't discovered until late. This is why we've been encouraging people to treat the betas like they used to treat the RCs (at least, I've been doing what I can). They're ready for testing against, just not ready for

Re: [Python-Dev] Recent changes to PyCodeObject

2016-11-16 Thread Nathaniel Smith
Didn't 3.5 have to roll an extra last minute RC for an emergency abi-breaking bug fix, though? (Thinking of the windows runtime stuff.) On Nov 16, 2016 7:51 PM, "Nick Coghlan" wrote: > On 17 November 2016 at 10:44, Steve Dower wrote: > > On 16Nov2016

Re: [Python-Dev] Recent changes to PyCodeObject

2016-11-16 Thread Nick Coghlan
On 17 November 2016 at 10:44, Steve Dower wrote: > On 16Nov2016 1618, Ned Batchelder wrote: >> 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

Re: [Python-Dev] Recent changes to PyCodeObject

2016-11-16 Thread Steve Dower
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

[Python-Dev] Recent changes to PyCodeObject

2016-11-16 Thread Ned Batchelder
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