I know you got your answer to why the change occurred, but a patch to
update any outdated comments would be appreciated. :)
On Thu, 17 Nov 2016 at 07:55 Ned Batchelder wrote:
> On 11/17/16 10:09 AM, Cody Piersall wrote:
> > On Wed, Nov 16, 2016 at 6:18 PM, Ned Batchelder
> wrote:
> >> When I ad
On 11/17/16 10:09 AM, Cody Piersall wrote:
> On Wed, Nov 16, 2016 at 6:18 PM, 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.
On Wed, Nov 16, 2016 at 6:18 PM, 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 ri
, just not ready for general distribution (or for producing wheels for
general distribution).
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Nathaniel Smith"
Sent: 11/16/2016 20:19
To: "Nick Coghlan"
Cc: "Python Dev" ; "St
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 1618, Ned Batchelder wrote:
> >> Am I doing
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 a non-guaranteed interfac
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 tha
