argparse support for "python -m module" in help

[tebeka]

BPO	22240
Nosy	@tebeka, @ncoghlan, @jwilk, @zertrin, @SamuelMarks, @septatrix
Files	prog.diff: Patch prog2.diff: Patch prog3.diff: Patch prog3.diff: Patch prog-module-name-handler.patch: Patch for handling python -m syntax in argument parser ouptut patch.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2014-08-20.19:59:11.381>
labels = ['type-feature', 'library']
title = 'argparse support for "python -m module" in help'
updated_at = <Date 2021-08-08.22:41:00.591>
user = 'https://github.com/tebeka'

bugs.python.org fields:

activity = <Date 2021-08-08.22:41:00.591>
actor = 'Nils Kattenbeck'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2014-08-20.19:59:11.381>
creator = 'tebeka'
dependencies = []
files = ['36424', '36453', '36461', '36476', '48643', '50174']
hgrepos = []
issue_num = 22240
keywords = ['patch']
message_count = 23.0
messages = ['225586', '225608', '225669', '225831', '225834', '225838', '225862', '225863', '225865', '225911', '225913', '226578', '226606', '226622', '226697', '226706', '226707', '353987', '353989', '397764', '398076', '398698', '399244']
nosy_count = 9.0
nosy_names = ['tebeka', 'ncoghlan', 'peter.otten', 'bethard', 'jwilk', 'paul.j3', 'zertrin', 'samuelmarks', 'Nils Kattenbeck']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue22240'
versions = ['Python 3.5']

Linked PRs

• gh-66436: Improved prog default value for argparse.ArgumentParser #124799

[tebeka]

"python -m module -h" starts with
usage: __main__.py

It should be
usage: python -m module

[ncoghlan]

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 a "-m" invocation
• __main__.__spec__.name will give you the module name that was executed
• if it is exactly "__main__" then this is likely zipfile or directory execution, and sys.argv[0] will still give the correct name
• if it ends with a ".__main__", it is likely package execution, and the last segment should be dropped
• otherwise, it is normal module execution

In the latter two cases, sys.executable can be used to figure out what to put before the "-m" (we don't expose the raw C level argv to Python, although there is an open RFE to do so somewhere on the tracker).

[tebeka]

For zip file the help should probably be:
usage: python file.zip

[tebeka]

New patch with handling of zip files.

[paulj3]

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

[paulj3]

What if the package is run without -m?

[tebeka]

Made the test more robust by using sys.executable in the comparison.

[tebeka]

How can you run a package without -m?

[paulj3]

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.

[ncoghlan]

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 execute the equivalent of "python3 -m __main__"

In the second case, the current directory will be added to sys.path, and python will execute the equivalent of "python3 -m subdir.__main__"

The first case is the directory execution support that was added way back in Python 2.6.

The second case is a combination of the package execution support added in Python 2.7/3.1 and the implicit namespace packages support that was added in Python 3.3.

Interesting find - the possibility of the latter situation hadn't occurred to me before :)

[tebeka]

Support for directory invocation as well.

[tebeka]

Anything else I need to solve to get this patch accepted?

[paulj3]

When I apply prog3.diff to my 3.5.0dev, and run

python3 -m unittest [Lib/test/test_argparse.py](https://github.com/python/cpython/blob/main/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 nosetests (though I'm not setup to use that in the development version).