Closed 4230aa88-8b9f-4430-91a2-a1ccaab97246 closed 9 years ago
This works correctly on Python 3.4.
On Python 2.7, argparse seems to completely and silently ignore arguments in some conditions, for instance this setup will cause --verbose to be ignored on the main parser:
options = argparse.ArgumentParser(add_help=False)
options.add_argument('-v', '--verbose', action='store_true')
parser = argparse.ArgumentParser(parents=[options])
subparsers = parser.add_subparsers()
parser_cmd = subparsers.add_parser('cmd', parents=[options])
Full runnable example here: http://paste.pound-python.org/show/XfVVhdJHSPISXLP1lASd/
Might or might not be related to bpo-9351, workarounds welcome.
Interestingly, this worked before my upgrade 2.7.8 -> 2.7.9.
honcho has been affected by this: https://github.com/nickstenning/honcho/issues/122
Working around the problem is possible but not very pretty: https://github.com/nickstenning/honcho/pull/121
I might use your workaround in ReproZip (https://github.com/ViDA-NYU/reprozip/issues/89), thanks. I agree that it doesn't look pretty...
Without actually running this case I think it is caused by the http://bugs.python.org/issue9351 patch.
You can check the __call__ method for class _SubParsersAction and how it handles invocation of the subparser. Does it get the existing namespace, or a new one (None)?
There is an inherent ambiguity when the same argument ('dest' actually) is defined for both the parser and the subparser. Doubly so when both get it via 'parents'. Which default and which argument string has priority?
That other issue tried to fix the case where the subparser's default was being ignored, and in the process created a case where the parser's argument string is being ignored.
Wouldn't it be safer all around if the subparsers took different arguments, or at least different namespace 'dest', than the main parser?
Wouldn't it be safer all around if the subparsers took different arguments, or at least different namespace 'dest', than the main parser?
IMHO, yes. I agree that the semantics of what the original code is trying to do is quite ambiguous. Since the documentation says that parents= causes all the given parsers and adds their options to the parser being constructed, I'd take that to mean that the -v before the command, and the command's -v would point to the same dest. The admonition for add_help=False seems to reinforce that.
The fact that this used to work should be considered an accident. I wouldn't call it a regression because the documentation does not make it clear that this should work. I think this is not a bug.
Feel free to reopen this if you disagree and and cite a convincing argument for sharing dests. To be totally unambiguous, use different destinations.
FWIW, I've never used parents myself. I've always done something like what honcho eventually landed.
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: ```python assignee = None closed_at =
created_at =
labels = ['invalid', 'type-bug', 'library']
title = 'argparse silently ignores arguments'
updated_at =
user = 'https://github.com/remram44'
```
bugs.python.org fields:
```python
activity =
actor = 'barry'
assignee = 'none'
closed = True
closed_date =
closer = 'barry'
components = ['Library (Lib)']
creation =
creator = 'remram'
dependencies = []
files = []
hgrepos = []
issue_num = 23058
keywords = []
message_count = 6.0
messages = ['232679', '232682', '233040', '233314', '239433', '242201']
nosy_count = 7.0
nosy_names = ['barry', 'gregory.p.smith', 'r.david.murray', 'nailor', 'paul.j3', 'remram', 'Changaco']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue23058'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']
```