Attached patch migrates unittest to argparse.This doesn't make discover handling much saner, given the awful way it's originally implemented.

What's the benefit of this change?

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.

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.

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?

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

> 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 apytest utility that does discovery automatically, and leave "python -munittest" as the lesser, undocumented option.

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. "./pythonLib/test/test_bisect.py discover"). At least USAGE_FROM_MODULE did not mention this mode.

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

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.

Is the patch good?

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.

> 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:    ./pythonLib/test/test_colorsys.py discover -vLib/test/test_json/or    ./python -m test.test_colorsys discover -vLib/test/test_json/But this looks as an unintentional and senseless ability.

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

New changeset340f45374cf5 by Serhiy Storchaka in branch 'default':Issue#17974: Switch unittest from using getopt to using argparse.http://hg.python.org/cpython/rev/340f45374cf5