[issue22240] argparse support for "python -m module" in help

Nils Kattenbeck added the comment: I implemented the logic and adjusted the existing tests to have a fixed program name. I also fixed the build error by changing how zip files are detected. Based on you comment Nick you however even had a different idea. Currently I check if

[issue22240] argparse support for "python -m module" in help

Change by Jakub Wilk : -- nosy: +jwilk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22240] argparse support for "python -m module" in help

Nick Coghlan added the comment: (Note: this is an old enough ticket that it started out with patch files on the tracker rather than PRs on GitHub. That's just a historical artifact, so feel free to open a PR as described in the devguide if you would prefer to work that way) There are two

[issue22240] argparse support for "python -m module" in help

Nils Kattenbeck added the comment: I expanded the patch from tebeka to also work with invocations like `python3 -m serial.tools.miniterm` where `miniterm.py` is a file and not a directory with a `__main__.py`. This was able to handle everything I threw at it. However due to the import of

[issue22240] argparse support for "python -m module" in help

Nils Kattenbeck added the comment: I am not sure if the patch correctly handles calling a nested module (e.g. `python3 -m serial.tools.miniterm`). Would it also be possible to detect if python or python3 was used for the invocation? -- nosy: +Nils Kattenbeck

[issue22240] argparse support for "python -m module" in help

Samuel Marks added the comment: See https://bugs.python.org/msg353987 for manual test -- Added file: https://bugs.python.org/file48643/prog-module-name-handler.patch ___ Python tracker

[issue22240] argparse support for "python -m module" in help

Samuel Marks added the comment: Until this is accepted, I've modified my codebase: ``` from argparse import ArgumentParser ArgumentParser( prog=None if globals().get('__spec__') is None else 'python -m {}'.format(__spec__.name.partition('.')[0]) ) ``` -- nosy: +samuelmarks

[issue22240] argparse support for "python -m module" in help

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue22240] argparse support for "python -m module" in help

Changes by zertrin : -- nosy: +zertrin ___ Python tracker ___ ___ Python-bugs-list

[issue22240] argparse support for python -m module in help

Miki Tebeka added the comment: Thanks Paul, will work on that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___ Python-bugs-list

[issue22240] argparse support for python -m module in help

paul j3 added the comment: One way to reduce the testing burden, and to be extra safe regarding backward compatibility is to make this action optional, rather than the default. For example, make `_prog_name` importable (i.e. change the name), and then expect the user to use it explicitly

[issue22240] argparse support for python -m module in help

Miki Tebeka added the comment: I don't like changing code just to accommodate testing. Will try to think of a way to solve this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___

[issue22240] argparse support for python -m module in help

Miki Tebeka added the comment: Anything else I need to solve to get this patch accepted? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___

[issue22240] argparse support for python -m module in help

Changes by Berker Peksag berker.pek...@gmail.com: -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___

[issue22240] argparse support for python -m module in help

paul j3 added the comment: When I apply `prog3.diff` to my 3.5.0dev, and run python3 -m unittest Lib/test/test_argparse.py I get 2 failures, both over 'usage: python3 -m [unit]test'. It also fails with python3 test_argparse.py I suspect it would also fail if I ran the tests with

[issue22240] argparse support for python -m module in help

paul j3 added the comment: In argparse.py, I would put a utility function like `_prog_name` near the start in the 'Utility functions and classes' block. In test_argparse.py, I don't see the purpose of the `progname` changes in the TestParentParsers class. That class wasn't producing an

[issue22240] argparse support for python -m module in help

Nick Coghlan added the comment: If you have: curdir /subdir __main__.py Then in 3.3+, both of the following will work: python3 subdir python3 -m subdir They do slightly different things, though. In the first case, subdir will be added to sys.path, and then python will

[issue22240] argparse support for python -m module in help

Miki Tebeka added the comment: Support for directory invocation as well. -- Added file: http://bugs.python.org/file36476/prog3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___

[issue22240] argparse support for python -m module in help

Miki Tebeka added the comment: New patch with handling of zip files. -- Added file: http://bugs.python.org/file36453/prog2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___

[issue22240] argparse support for python -m module in help

paul j3 added the comment: The patch tests assume the test is being run in a particular way: python -m unittest ... But I often use python3 -m unittest ... or python3 test_argparse.py both of which fail these tests. Testing this change might be more difficult than implementing

[issue22240] argparse support for python -m module in help

paul j3 added the comment: What if the package is run without `-m`? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___

[issue22240] argparse support for python -m module in help

Miki Tebeka added the comment: How can you run a package without -m? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___

[issue22240] argparse support for python -m module in help

Miki Tebeka added the comment: Made the test more robust by using sys.executable in the comparison. -- Added file: http://bugs.python.org/file36461/prog3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240

[issue22240] argparse support for python -m module in help

paul j3 added the comment: Package might be the wrong term. How about a directory with a `__main__.py` file, and no local imports (relative or not)? In my tests it runs with and without the -m. -- ___ Python tracker rep...@bugs.python.org

[issue22240] argparse support for python -m module in help

Miki Tebeka added the comment: For zip file the help should probably be: usage: python file.zip -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___

[issue22240] argparse support for python -m module in help

Changes by Brett Cannon br...@python.org: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___ Python-bugs-list mailing

[issue22240] argparse support for python -m module in help

Nick Coghlan added the comment: I suspect resolving this will actually need special casing on the argparse side - __main__.__spec__ will have the original details for __main__ when executed via -m of zipfile/directory execution. Things to check for: * __main__.__spec__ is not None indicates

[issue22240] argparse support for python -m module in help

Changes by Peter Otten __pete...@web.de: -- nosy: +peter.otten ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___ Python-bugs-list

[issue22240] argparse support for python -m module in help

Changes by Mark Lawrence breamore...@yahoo.co.uk: -- nosy: +BreamoreBoy, paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___

[issue22240] argparse support for python -m module in help

New submission from Miki Tebeka: python -m module -h starts with usage: __main__.py It should be usage: python -m module -- components: Library (Lib) files: prog.diff keywords: patch messages: 225586 nosy: tebeka priority: normal severity: normal status: open title: argparse