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

Can you put the whole traceback? I'm unable to reproduce the issue. Which datetime test uses biesct?

The key is how the test is run.  If you run:

$ ./python Lib/test/<some script>.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.

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.

> 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?

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 <test name>" 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.

> 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.

stage: needs patch -> resolved

messages: + msg301296