Issue 24285: regression for importing extensions in packages
This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :) --Ned.
On 28 May 2015 at 12:51, Ned Batchelder
This issue has been fixed, but a day or two late for 3.5b1.
Aye, we only found out about the missing test case via feedback *on* the beta. We had never needed to worry about it before, but it turns out all our extension modules in the standard library are top level modules and we didn't previously have an explicit test for the submodule case :(
It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :)
Until your email, I hadn't fully thought through the consequences, but the bug is actually going to block a *lot* of potential testing of the beta release - anything that requires a C extension module that isn't a top level module isn't going to work with 3.5b1. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 2015-05-27 11:02 PM, Nick Coghlan wrote:
It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :) Until your email, I hadn't fully thought through the consequences, but the bug is actually going to block a*lot* of potential testing of the beta release - anything that requires a C extension module that isn't a top level module isn't going to work with 3.5b1.
It would also be great to release the new beta shortly with the new OrderedDict implemented in C and math.isclose(). Yury
Nick Coghlan schrieb am 28.05.2015 um 05:02:
On 28 May 2015 at 12:51, Ned Batchelder wrote:
This issue has been fixed, but a day or two late for 3.5b1.
Aye, we only found out about the missing test case via feedback *on* the beta. We had never needed to worry about it before, but it turns out all our extension modules in the standard library are top level modules and we didn't previously have an explicit test for the submodule case :(
It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :)
Until your email, I hadn't fully thought through the consequences, but the bug is actually going to block a *lot* of potential testing of the beta release - anything that requires a C extension module that isn't a top level module isn't going to work with 3.5b1.
+1 for a quick beta 2 from me, too (obviously). I've already seen a bug report because a Cython compiled package doesn't work in Py3.5. Having to tell them to wait a while for beta 2 is annoying and discouraging for early testers. Stefan
On 05/27/2015 08:02 PM, Nick Coghlan wrote:
This issue has been fixed, but a day or two late for 3.5b1. Aye, we only found out about the missing test case via feedback *on*
On 28 May 2015 at 12:51, Ned Batchelder
wrote: the beta. We had never needed to worry about it before, but it turns out all our extension modules in the standard library are top level modules and we didn't previously have an explicit test for the submodule case :(
Well, certainly this sounds like something that needs to go into the regression test suite. Can someone create the issue? ... and the patch? //arry/
On 05/27/2015 10:35 PM, Larry Hastings wrote:
Well, certainly this sounds like something that needs to go into the regression test suite. Can someone create the issue?
... and the patch?
NM, the existing fix already added a test to the regression test suite. I should have read the issue first! //arry/
On 05/27/2015 07:51 PM, Ned Batchelder wrote:
This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :)
On 28 May 2015 at 14:30, Larry Hastings
On 05/27/2015 07:51 PM, Ned Batchelder wrote:
This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :)
Aye, it's the long gap from May 24 (3.5b1) to July 5 (3.5b2) that we were hoping to see shortened if it was possible to get the release team together. The fact folks can't currently import extension modules that aren't at top level is unfortunately going to limit the amount of 3.5b1 testing the community can do in those 6 weeks :( Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, May 27, 2015 at 9:54 PM, Nick Coghlan
On 28 May 2015 at 14:30, Larry Hastings
wrote: On 05/27/2015 07:51 PM, Ned Batchelder wrote:
This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :)
Aye, it's the long gap from May 24 (3.5b1) to July 5 (3.5b2) that we were hoping to see shortened if it was possible to get the release team together.
The fact folks can't currently import extension modules that aren't at top level is unfortunately going to limit the amount of 3.5b1 testing the community can do in those 6 weeks :(
Just chiming in to confirm that yep, numpy (and thus the whole numerical stack) are also missing on 3.5b1. Of course this was filed as a bug report on numpy :-): https://github.com/numpy/numpy/issues/5915 I guess the good news is that people are in fact testing the beta, but it sounds like pretty much the only code running on b1 is pure Python code whose entire dependency chain is also pure Python code. On the upside, compatibility between PyPy and CPython has improved greatly ;-). -n -- Nathaniel J. Smith -- http://vorpus.org
participants (6)
-
Larry Hastings
-
Nathaniel Smith
-
Ned Batchelder
-
Nick Coghlan
-
Stefan Behnel
-
Yury Selivanov