On 4 July 2017 at 22:10, Victor Stinner
2017-07-04 13:22 GMT+02:00 Nick Coghlan
: That means if test.bisect is shadowing the top level bisect module when backported, it suggests that the test.regrtest directory is ending up on sys.path for the affected test run (e.g. because the tests were run as "python Lib/test/regrtest.py" rather than via the -m switch).
I don't think that Lib/test/ is in sys.path. It's more subtle than test. When you run "./python -m test test_bisect", Lib/test/regrtest.py imports "test.test_bisect", and so test_bisect is imported with __package__=['test'].
With test_bisect.__package__=['test'], "import bisect" in Lib/test/test_bisect.py imports Lib/test/bisect.py.
Right, for test_bisect specifically, the implicit relative import problem applies, and "from __future__ import absolute_import" is the relevant fix. That concern just doesn't apply to the *stdlib* modules doing a normal top-level "import bisect".
The question is more when Lib/multiprocessing/heap.py got Lib/test/bisect.py instead of Lib/bisect.py. I didn't dig into this issue. The Python 2 import machinery blows my mind :-)
*This* is the case that I think is due to "Lib/test" being on sys.path when the tests are run: ``` $ ./python -i Lib/test/regrtest.py --help [snip output]
import sys sys.path[0] '/home/ncoghlan/devel/py27/Lib/test'
Using test_urllib2 as the example:
$ touch Lib/test/bisect.py $ ./python -m test.regrtest test_urllib2 Run tests sequentially 0:00:00 [1/1] test_urllib2 1 test OK. Total duration: 800 ms Tests result: SUCCESS $ ./python Lib/test/regrtest.py test_urllib2 Run tests sequentially 0:00:00 [1/1] test_urllib2 Warning -- os.environ was modified by test_urllib2 [snip output] test test_urllib2 failed -- multiple errors occurred; run in verbose mode for details 1 test failed: test_urllib2 Total duration: 107 ms Tests result: FAILURE ``` Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia