msg189212 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2013-05-14 12:34 |
Attached patch migrates unittest to argparse. This doesn't make discover handling much saner, given the awful way it's originally implemented. |
|
|
msg189213 - (view) |
Author: Michael Foord (michael.foord) *  |
Date: 2013-05-14 12:36 |
What's the benefit of this change? |
|
|
msg189215 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2013-05-14 12:45 |
I was considering making it possible to customize command-line options, as requested by Guido, and it's better to expose the modern API rather than the more obsolete one. |
|
|
msg189217 - (view) |
Author: Michael Foord (michael.foord) *  |
Date: 2013-05-14 13:13 |
Ok, feel free to reimplement discovery command line handling if it can be done in a compatible-but-less-horrible way. Anyway, the patch looks fine and a couple of minor cleanups in there. |
|
|
msg189218 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2013-05-14 13:43 |
I don't see much sense in this modernization, while the code does not use the capabilities of argparse (and even optparse). Why USAGE_AS_MAIN/USAGE_FROM_MODULE/etc exist, why help is not generated automatically? Why -v/-q store boolean flags instead of changing the numerical level of verbosity? |
|
|
msg189220 - (view) |
Author: Michael Foord (michael.foord) *  |
Date: 2013-05-14 13:58 |
Test discovery and new options (buffer, failfast etc) were bolted onto an old and ugly design. Yes the code could use an overhaul and rebuilding from scratch - but doing that whilst remaining fully compatible with all the existing usage patterns is "difficult". |
|
|
msg189236 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2013-05-14 16:44 |
> Ok, feel free to reimplement discovery command line handling if it can > be done in a compatible-but-less-horrible way. I don't think it's possible. Best way forward would be to provide a pytest utility that does discovery automatically, and leave "python -m unittest" as the lesser, undocumented option. |
|
|
msg189254 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2013-05-14 23:04 |
Here is a patch which reimplement discovery command line handling in a i-hope-in-compatible-but-less-horrible way (and fixes some bugs). It is horrible still, but I doubt how many changes can I do without breaking compatibility. If _do_discovery() used only in tests, I can clean the code more. I suppose discovery mode doesn't make sense when unittest.main() is called from a test module (i.e. "./python Lib/test/test_bisect.py discover"). At least USAGE_FROM_MODULE did not mention this mode. |
|
|
msg189279 - (view) |
Author: Michael Foord (michael.foord) *  |
Date: 2013-05-15 09:36 |
Discovery from a module importing main doesn't make sense (although from a *script* importing main it does). So long as "python -m unittest -v" continues to launch discovery, and the "positional argument" form of discovery still works, then the new patch looks good. I'll try it out and confirm. In general I agree with Antoine, the best way to improve the implementation of unittest.main is to provide a new discovery script (with supporting code that is then much easier to extend). |
|
|
msg189294 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2013-05-15 19:32 |
Here is other variant of patch, even less horrible. However it introduces some incompatibility: 1. Discovery mode now works only when module==None (i.e. from "-m unittest"). It is only case for which it was documented. 2. Previously unittest.main(failfast=False, argv=['prog', '-f']) caused an error, while unittest.main(failfast=True, argv=['prog', '-f']) and unittest.main(failfast=[], argv=['prog', '-f']) just had no any effect. Now all non-None casse cause an error. The same for catchbreak and buffer. |
|
|
msg194682 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2013-08-08 14:55 |
Is the patch good? |
|
|
msg194720 - (view) |
Author: Michael Foord (michael.foord) *  |
Date: 2013-08-09 09:20 |
The patch looks like an improvement. Does it maintain the ability to pass the discovery arguments positionally and by keyword? If so then it can go in. I like the improved error reporting for nonsenical input to unittest.main. |
|
|
msg194721 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2013-08-09 10:00 |
> Does it maintain the ability to pass the discovery arguments positionally and by keyword? Yes, of course. Only such command line are not supported more: ./python Lib/test/test_colorsys.py discover -v Lib/test/test_json/ or ./python -m test.test_colorsys discover -v Lib/test/test_json/ But this looks as an unintentional and senseless ability. |
|
|
msg196447 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2013-08-29 09:01 |
I think this should be committed. This is the first step in making command-line args easily customizable (e.g. by exposing the parsers as a public API in TestProgram). |
|
|
msg196451 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-08-29 09:38 |
New changeset 340f45374cf5 by Serhiy Storchaka in branch 'default': Issue #17974: Switch unittest from using getopt to using argparse. http://hg.python.org/cpython/rev/340f45374cf5 |
|
|