GeezerVison is showing github.com — argparse support for "python -m module" in help · Issue #66436 · python/cpython
argparse support for "python -m module" in help #66436Description
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
Activitytebeka commented on Aug 20, 2014 MannequinAuthor More actions "python -m module -h" starts with
usage: __main__.py
It should be
usage: python -m module ncoghlan commented on Aug 21, 2014 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 commented on Aug 22, 2014 MannequinAuthor More actions For zip file the help should probably be:
usage: python file.zip tebeka commented on Aug 24, 2014 MannequinAuthor More actions New patch with handling of zip files. paulj3 commented on Aug 24, 2014 The patch tests assume the test is being run in a particular way:
But I often use
or
both of which fail these tests.
Testing this change might be more difficult than implementing it. paulj3 commented on Aug 24, 2014 What if the package is run without -m? tebeka commented on Aug 25, 2014 MannequinAuthor More actions Made the test more robust by using sys.executable in the comparison. tebeka commented on Aug 25, 2014 MannequinAuthor More actions How can you run a package without -m? paulj3 commented on Aug 25, 2014 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 commented on Aug 26, 2014 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 commented on Aug 26, 2014 MannequinAuthor More actions Support for directory invocation as well. tebeka commented on Sep 8, 2014 MannequinAuthor More actions Anything else I need to solve to get this patch accepted? paulj3 commented on Sep 8, 2014 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
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). serhiy-storchaka commented on Sep 30, 2024 #124799 mostly implements @ncoghlan's algorithm from #66436 (comment) and adds tests and documentation.
@ncoghlan, I would appreciate your review of the documentation, as it is difficult to me. Feel free to rewrite it completely. Reacted by Alyssa Coghlan serhiy-storchaka commented on Oct 1, 2024 It looks to me that testing __main__.__spec__.name for '__main__' is enough. Additional checks are redundant, and checking that sys.argv[0] is equal to __main__.__spec__.origin with the trailing __main__.py removed is hard due to difference in normalization on Unix and Windows. added a commit that references this issue on Oct 1, 2024gh-66436: Improved prog default value for argparse.ArgumentParser (GH…
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|