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
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
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
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
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