[Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)
Victor Stinner
victor.stinner at gmail.com
Tue Jul 4 08:10:14 EDT 2017
More information about the Python-Dev mailing list
Tue Jul 4 08:10:14 EDT 2017
- Previous message (by thread): [Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)
- Next message (by thread): [Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2017-07-04 13:22 GMT+02:00 Nick Coghlan <ncoghlan at gmail.com>: > 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. 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 :-) Victor
- Previous message (by thread): [Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)
- Next message (by thread): [Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list