[issue10470] python -m unittest ought to default to discovery

2010-11-22 Thread Michael Foord
Michael Foord added the comment: Eli - I quite agree. TestProgram is a *particularly* obscure part of unittest. A much better solution (well - both would be ideal) would be to refactor the code so that it isn't so obscure. TestProgram is an artefact of unittest's history and should be a serie

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Eli Bendersky added the comment: Michael, I feared this might be the case. Without knowing the module deeply, it's not easy to be aware of all the possible paths, preconditions, and consequences (and tests obviously didn't catch that). A suggestion - maybe documenting these parts would allow

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Michael Foord
Michael Foord added the comment: Committed revision 86649. -- resolution: -> accepted stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Michael Foord
Michael Foord added the comment: Sorry for the late reply. I don't think the patch as provided is sufficient as it would interfere with people causing unittest.main() directly from a test module. Checking that TestProgram.loader is None is the way to detect we have been launched from the comm

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Changes by Eli Bendersky : -- Removed message: http://bugs.python.org/msg121918 ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Changes by Eli Bendersky : -- Removed message: http://bugs.python.org/msg121909 ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Changes by Eli Bendersky : Removed file: http://bugs.python.org/file19741/unittest.test.test_program.diff ___ Python tracker ___ ___ Python-bu

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Changes by Eli Bendersky : Removed file: http://bugs.python.org/file19738/unittest.main.diff ___ Python tracker ___ ___ Python-bugs-list maili

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Eli Bendersky added the comment: Submitting a complete patch file for this: 1. Modified Lib/unittest/main.py to implement the change 2. Modified Lib/unittest/test/test_program.py to make the tests pass without warnings from regrtest.py 3. Updated the documentation in Doc/library/unittest.rst 4

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Eli Bendersky added the comment: Attaching a patch to unittest/test/test_program.py that fixes the sys.path warning in regrtest What happens is that with the new capability added to unittest (running discovery when called as -m without args), a few tests in test_program now cause discovery t

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Eli Bendersky added the comment: I'm attaching a patch for unittest/main.py that implements this. However, something is funny with the tests of the unittest module. When the patch is applied and the tests are run through regrtest.py, it complains that sys.path is modified. I'm investigating t

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Changes by Eli Bendersky : -- Removed message: http://bugs.python.org/msg121903 ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Eli Bendersky
Eli Bendersky added the comment: I will take a shot at this now. If there's anything special I should look out for, let me know :) -- nosy: +eli.bendersky ___ Python tracker __

[issue10470] python -m unittest ought to default to discovery

2010-11-21 Thread Michael Foord
Michael Foord added the comment: @Eric No. "python -m unittest discover ..." will still be needed where you want to pass arguments to discovery ("python -m unittest ..." still has a different meaning where you pass arguments). All this will do is give the previously useless "python -m unitte

[issue10470] python -m unittest ought to default to discovery

2010-11-20 Thread Duncan Findlay
Changes by Duncan Findlay : -- nosy: +duncf ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue10470] python -m unittest ought to default to discovery

2010-11-20 Thread Éric Araujo
Changes by Éric Araujo : -- keywords: +easy stage: -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue10470] python -m unittest ought to default to discovery

2010-11-20 Thread Éric Araujo
Éric Araujo added the comment: The existing discover subcommand would enter the deprecation process, right? -- nosy: +eric.araujo ___ Python tracker ___

[issue10470] python -m unittest ought to default to discovery

2010-11-20 Thread Michael Foord
New submission from Michael Foord : "python -m unittest" does nothing useful (runs 0 tests). It would be good to have it default to discovery, which removes the useless behaviour *and* makes the default invocation for test discovery shorter. -- assignee: michael.foord components: Libra