| msg301271 - (view) |
Author: Neil Schemenauer (nascheme) *  |
Date: 2017-09-04 21:48 |
| After a lot of head scratching, I have discovered why tests are failing for me. E.g. "./python Lib/test/test_datetime.py" results in AttributeError: module 'bisect' has no attribute 'bisect_right' Running tests this way causes test/bisect to be imported rather than the std library bisect module. I'm not sure of the correct fix, perhaps rename test.bisect? Patch that added it: bpo-29512: Add test.bisect, bisect failing tests |
|
|
| msg301288 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2017-09-05 00:03 |
| Can you put the whole traceback? I'm unable to reproduce the issue. Which datetime test uses biesct? |
|
|
| msg301296 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2017-09-05 04:28 |
| The key is how the test is run. If you run: $ ./python Lib/test/.py Then the Lib/test gets added to the first part of sys.path. Then "import bisect" imports the Lib/test/bisect.py module rather than Lib/bisect.py. Obvious options seem to be: 1. rename Lib/test/bisect.py to something else 2. don't allow running files in Lib/test as scripts To me, #2 is not a good option. I'm attaching the output of: ./python.exe Lib/test/regrtest.py -v test_datetime 2>&1 In case it is helpful. I pruned some lines to keep the file smaller. |
|
|
| msg321761 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2018-07-16 19:41 |
| This is still broken, IMHO. Either we should rename test.bisect or we should remove all of the 'if __name__ == "__main__"' part of the test scripts. You can't run the tests reliably as scripts anymore. Doing so puts Lib/test into sys.path. Then, anything that imports 'bisect' (e.g. the random module) will get test.bisect and not the real bisect module. I tried making it so that test.bisect could not be imported as bisect but I can't think of a way. E.g. adding to test/__init__.py import test._bisect as bisect sys.modules['test.bisect'] = bisect does not work. I don't understand the import system good enough to think of a solution. |
|
|
| msg321774 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2018-07-16 22:08 |
| > This is still broken, IMHO. Either we should rename test.bisect (...) I renamed it: commit 823c295efa4efea93cadc640ed6122cd9d86cec4 Author: Victor Stinner <vstinner@redhat.com> Date: Wed May 30 17:24:40 2018 +0200 bpo-29512: Rename Lib/test/bisect.py to bisect_cmd.py (#7229) Can we close this issue a duplicate of bpo-29512? |
|
|
| msg321785 - (view) |
Author: Neil Schemenauer (nascheme) * |
Date: 2018-07-17 01:50 |
| Yes, it looks like the same issue as bpo-29512. Renaming test.bisect is the simplest solution. I have trained myself to run "python -m test.regrtest " so this issue doesn't affect me any more. However, I think it was a trap that will catch some people. So, thanks for fixing. I considered adding a 'bisect' command to the test/__main__, e.g. you could run 'python -m test --bisect ..'. That looks not entirely simple to implement though. |
|
|
| msg321814 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2018-07-17 11:27 |
| > I considered adding a 'bisect' command to the test/__main__, e.g. you could run 'python -m test --bisect ..'. That looks not entirely simple to implement though. Ah yes, for the long term, integrating test.bisect directly in libregrtest would be great, but I don't see how to modify the existing libregrtest CLI. test.bisect comes with its set of options like -i, -o, -n. Maybe it's fine to have a separated tool and file. |
|
|