homepage

$ python3.4 -m trace -l 
Traceback (most recent call last):
 File "/usr/local/lib/python3.4/runpy.py", line 170, in _run_module_as_main
 "__main__", mod_spec)
 File "/usr/local/lib/python3.4/runpy.py", line 85, in _run_code
 exec(code, run_globals)
 File "/usr/local/lib/python3.4/trace.py", line 858, in <module>
 main()
 File "/usr/local/lib/python3.4/trace.py", line 787, in main
 progname = prog_argv[0]
IndexError: list index out of range
I would expect something more clear to be printed, like the program usage helper you get in this case:
$ python3.4 -m trace 
/usr/local/lib/python3.4/trace.py: must specify one of --trace, --count, --report, --listfuncs, or --trackcalls

Here is the patch.

Thanks, Berker Peksag, for the review. Here is the updated patch with the test.

I reviewed the patch. It looks like the problem is not just with list functions but with other options too. Like.
$ ./python.exe -m trace -t
$ ./python.exe -m trace -c
$ ./python.exe -m trace -T
Will throw the same error. So, any changes should address all these cases instead of a single listfunctions (-l) case only.

I could submit a patch, but I'd switch over from getopt to argparse. I think this exactly the case when such a change is warranted.

@SilentGhost, I agree with you. I am making the change to use argparse as part of this issue24649. And this bug could be covered as part of the change to argparse.

Here is the patch that incorporates earlier changes from Vajrasky's patch as well as wording from Evan's patch in issue24649. I've extended the test of failures, but I'm not sure if much can be done about the test of successful executions. I'm going to mark this issue as a superseder of the issue24649.

@SilentGhost,
Thanks a lot for the quick turn around of a patch. I have left some review comments in reitveld. Please address them.
Since this is underlying implementation change in option processing/parsing, it should only in feature release (3.6). 
Thank you!

Here is the updated version of the patch that addresses Senthil's comments. Besides re-flowing code, I've also added enforcement of --summary switch and re-factored and expanded the test_failures. It probably would be good if someone could test this on a real-life code.

New changeset 0aa46b9ffba3 by Senthil Kumaran in branch 'default':
Issue22642 - Convert trace module's option handling mechanism from getopt to argparse.
https://hg.python.org/cpython/rev/0aa46b9ffba3 

New changeset 69aa17b1f894 by Senthil Kumaran in branch 'default':
Add a NEWS entry for Issue #22642.
https://hg.python.org/cpython/rev/69aa17b1f894 

Thanks for the contribution. The option handling of trace module is modernized now.
As berker suggested in one of the review comments, this module could see an increase in test coverage and we could deal with this as separate ticket.

Thanks, Senthil. My comment was for Vajrasky's patch, not for the whole argparse switch. We need to add tests for the old getopt code first to avoid regressions. After 0aa46b9ffba3, if we add tests we won't be able to test the old interface.
My other comments:
* SilentGhost needs to fill the contributor's agreement form. We generally accept trivial patches without asking CA, but I think we can't accept 0aa46b9ffba3 without one since the patch is huge.
* I don't think we add reST formatted docstring to stdlib. The javadoc style one in Trace.__init__() is 13 years old so we can ignore it.
* I also have some minor comments, but I don't think they are important at this point :)