[issue12686] argparse - document (and improve?) use of SUPPRESS with help=
Steven Bethard added the comment: Yeah, looks like we can close this. If anyone finds a specific bug in the use of SUPPRESS, please open a new issue. -- resolution: - duplicate status: open - closed superseder: - document argparse's help=SUPPRESS ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12686 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15935] clarify argparse docs re: add_argument() type and default arguments
Steven Bethard added the comment: Looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15929] argparse non alphanum characters replacement
Steven Bethard added the comment: If you need to get things that aren't valid Python identifiers, use vars() to get the dictionary: http://docs.python.org/dev/library/argparse.html#the-namespace-object Changing all non-alphanumeric characters to underscores would be a backwards incompatible change for argparse (it would break existing code). That means we'd need to have a long deprecation period before the change. I'm not sure it's really worth it for this feature when vars() already gives you what you need easily. I'm therefore closing this a won't fix, but if you feel really strongly that vars() doesn't solve your problem and you want to push through the long deprecation process, feel free to re-open. @R. David Murray: I wouldn't worry about non-identifiers in an attribute dict. This has worked for ages, and changing this would be a seriously backwards incompatible change that couldn't be possible before Python 4. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15929 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15906] argparse add_argument() confusing behavior when type=str, default=
Steven Bethard added the comment: It looks like the correct fix was already applied, but just to chime in here: (1) Yes, the error is that the isinstance(action.default, str) check was lost (2) Yes, it is intended that you can use a string value as your default and the type= converter will be called on that. This feature allows DRY for people that have a complex object that can be specified by a simple string. (3) Yes, the type= converter function should be applied to the default for all action types, not just for the store action. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15929] argparse non alphanum characters replacement
Steven Bethard added the comment: I haven't been following python-dev recently, but the only discussion I remember was for non-strings in __dict__, not non-identifiers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15929 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15906] argparse add_argument() confusing behavior when type=str, default=
Steven Bethard added the comment: Oh, I see, you're right - the recent changes from the Roundup Robot are exactly the wrong changes - special casing _StoreAction, not string defaults. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15906] argparse add_argument() confusing behavior when type=str, default=
Steven Bethard added the comment: I see. So right now, both string defaults and non-string defaults are being converted with the type= function. That seems suspect to me since the documentation explicitly says type= can take any callable that takes a single string argument and returns the converted value, so non-string defaults don't make sense to pass to that function. I believe test_type_function_call_with_non_string_default() comes from Arnaud Fontaine. Arnaud, can you comment on the intent of that test? My thoughts: * We should not be converting non-string defaults, or the documentation's description of the type= argument doesn't make sense. * For the string defaults, I can see the argument for not converting them, and the argparse docs never show them being converted from strings. I thought there was a discussion somewhere where someone had requested the current behavior, but I can't for the life of me find that discussion, so perhaps I'm imagining it... In terms of potential for breaking code, I'm not too worried about removing type conversion for non-string defaults - this never happened before the fix for #12776 and #11839, so I doubt much code depends on it. I am more worried about removing type conversion for string defaults - this has worked for a long time, so there probably is some code that depends on it. -- nosy: +arnau ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15906] argparse add_argument() confusing behavior when type=str, default=
Steven Bethard added the comment: Ok, sounds good. Let's make the test check the documented behavior, and then add back the isinstance(action.default, str) check. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15906] argparse add_argument() confusing behavior when type=str, default=
Steven Bethard added the comment: Patch, with the basestring amendment, looks good. Do we need a new test for conversion of string defaults? Yeah, I guess go ahead and add one. That will at least document our intentions here, and if we decide to change that later, then it will force us to deprecate the conversion of string defaults first (which we probably should if we're going to.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Steven Bethard added the comment: Interesting idea! The regex would need a little extra care to interoperate properly with prefix_chars, but the approach doesn't seem crazy. I'd probably call the constructor option something like args_default_to_positional (the current behavior is essentially that args default to optional arguments if they look like optionals). I'd be happy to review a patch along these lines. It would probably be good if Anders Kaseorg could also review it to make sure it fully solves his problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15874] argparse cannot parse shell variable arguments in file-given arguments
Steven Bethard added the comment: You could try declaring a type converter and using the type= parameter of add_argument. Your type converter could look something like: def expanded_path(arg): return os.path.expandvars(arg) Would that work? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15847] parse_args stopped accepting tuples
Steven Bethard added the comment:
The fix looks about right to me.
There's a bug in the tests though:
parser.parse_args(('x'))
should probably be:
parser.parse_args(('x',))
since I assume the intent was to test tuples.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15847
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15832] argparse: typechecks default value too early
Changes by Steven Bethard steven.beth...@gmail.com: -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15832] argparse: typechecks default value too early
Steven Bethard added the comment: It's a bug, but it's already been reported in Issue 12776. There's a patch there, but someone needs to commit it. -- superseder: - argparse: type conversion function should be called only once ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13922] argparse handling multiple -- in args improperly
Steven Bethard added the comment: @gcbirzan: Could you please open up a new issue? The current issue is fixed - it's just that the fix caused a new issue. I would say that the `args` parameter was never intended to be anything but a list, so currently there's a documentation bug since that isn't stated explicitly anywhere. (But certainly the tests only test for lists, not any other sequences.) Adding support for stuff other than lists feels more like a feature request, but given that it apparently worked by accident before, I guess we need to treat it as a bug. Probably the fix for that bug needs to have a ton of tests that check whether tuples work in all the various ways that parse_args is used. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15433] argparse usage line is wrong
Changes by Steven Bethard steven.beth...@gmail.com: -- resolution: - duplicate superseder: - argparse optionals with nargs='+' can't be followed by positionals ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15433 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15433] argparse usage line is wrong
Changes by Steven Bethard steven.beth...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15433 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals
Steven Bethard steven.beth...@gmail.com added the comment: So Kotan's patch doesn't actually solve the original problem. Instead, it inserts the workaround into the help message of the parser. I think this is probably not the right fix. We should probably do two things: (1) Right now: create a documentation patch which at least explains the current limitations of argparse parsing, and describes the '--' workaround. Probably this patch should add a separate section about '--', give an example like the one in this issue, and then cross-reference this section from nargs='?', nargs='*', nargs='+' and the Arguments containing - section. (2) Longer term: create a code patch that implements the changes to the regular expression-based parsing like I've suggested. -- title: argparse optionals with nargs='+' can't be followed by positionals - argparse optionals with nargs='?', '*' or '+' can't be followed by positionals ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9338 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals
Steven Bethard steven.beth...@gmail.com added the comment: And I guess Issue 9182 is the right place for (1). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9338 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] document “--” as a way to distinguish option w/ narg='+' from positional argument in argparse
Steven Bethard steven.beth...@gmail.com added the comment: Ok, here's what I think needs to go into the documentation here: (1) Add a separate section to the argparse docs about '--'. Give examples like the ones in this issue, and show how '--' can solve them (2) Cross-reference the section on '--' from nargs='?', nargs='*', nargs='+' and the Arguments containing - sections (and any other places where people are likely to run into the need for '--'). All of these changes should be on Doc/library/argparse.rst - I don't think we want to change the code at the moment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Steven Bethard steven.beth...@gmail.com added the comment: I've updated the patch for the current trunk. Should be ready to commit. -- Added file: http://bugs.python.org/file26490/Issue13249-4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Steven Bethard steven.beth...@gmail.com added the comment: I think it makes a lot of sense to allow people to disable abbreviations, so +1 on the feature request. The patch looked good. There was one typo - using accept_abbrev in the docstring instead of allow_abbrev as in the implementation, and I fixed that and uploaded a new patch. To be complete, the patch also needs to add some documentation, edit Misc/NEWS, etc. See: http://docs.python.org/devguide/patch.html#preparation -- versions: +Python 3.4 -Python 3.3 Added file: http://bugs.python.org/file26481/14910.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Steven Bethard steven.beth...@gmail.com added the comment: Sorry, my mistake, the doc changes were already in the patch. I just checked them and they look good too. So everything's ready to commit. Thanks for your contribution! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8538] Add FlagAction to argparse
Steven Bethard steven.beth...@gmail.com added the comment: On the off chance that someone was waiting for feedback from me, I'll say: (1) A simple boolean --foo/--no-foo action seems useful to me. I would probably call it BooleanOptionalAction rather than FlagAction. (Almost anything could be considered a flag.) (2) At the moment, argparse doesn't supply any actions, so I don't think we should make a separate namespace for them. If it starts to grow a list of such actions, we can add a separate namespace later. (And given that the name will end with Action, I think it should be pretty clear without the namespace.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
Steven Bethard steven.beth...@gmail.com added the comment: The fix looks right, but we definitely need a test. I tried to write one, but I'm not sure how to do this properly given how test_argparse redirects standard input and output (so that fileno() doesn't work anymore). I've attached my current (failing) attempt to test this. -- Added file: http://bugs.python.org/file26484/14156.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11354] argparse: nargs could accept range of options count
Steven Bethard steven.beth...@gmail.com added the comment:
The tests look like they're testing the right things, but the tests should
instead be written like the rest of the argparse tests. For example, look at
TestOptionalsNargs3 and TestPositionalsNargs2. You could write your tests to
look something like those, e.g.
class TestOptionalsNargs1_3(ParserTestCase):
argument_signatures = [Sig('-x', nargs=(1, 3))]
failures = ['a', '-x', '-x a b c d']
successes = [
('', NS(x=None)),
('-x a', NS(x=['a'])),
('-x a b', NS(x=['a', 'b'])),
('-x a b c', NS(x=['a', 'b', 'c'])),
]
Also, a complete patch will need to document the new feature in the Python
documentation, among other things. See the details described here:
http://docs.python.org/devguide/patch.html#preparation
--
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11354
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional
Steven Bethard steven.beth...@gmail.com added the comment: Your patch is a good start, but it needs to handle all the related situations, e.g. nargs='?' and the possibility of having more than one zero-length argument at the end. I believe the following patch achieves this. Please test it out. -- versions: +Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26485/15112.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15427] Describe use of args parameter of argparse.ArgumentParser.parse_args
New submission from Steven Bethard steven.beth...@gmail.com: From http://bugs.python.org/issue14191#msg155202: ArgumentParser.parse_args(args=None, namespace=None) ... However, nowhere is the args= parameter explained. One example is given at the end of 15.4.4.6 showing the use of args= which apparently accepts a list of parameters, similar to the positional list of parameters that are used in all the other examples. It might be nice to clarify that. -- assignee: docs@python components: Documentation messages: 166174 nosy: bethard, docs@python priority: normal severity: normal status: open title: Describe use of args parameter of argparse.ArgumentParser.parse_args type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Steven Bethard steven.beth...@gmail.com added the comment: I created Issue 15427 for the parse_args documentation bug. So let's make this issue just about parsing intermixed arguments. Yes, if someone would like to provide a patch for this, please create a method parse_intermixed_args rather than adding a boolean flag parameter. It should be basically equivalent to this code: args, remaining_args = optionals.parse_known_args() args = positionals.parse_args(remaining_args, args) Except that it should give proper error messages. There should be some tests to make sure both that it parses things as expected and that it gives error messages as expected. -- assignee: docs@python - components: -Documentation title: argparse: nargs='*' doesn't get out-of-order positional parameters - argparse doesn't allow optionals within positionals versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15271] argparse: repeatedly specifying the same argument ignores the previous ones
Steven Bethard steven.beth...@gmail.com added the comment: I don't think this is a bug. You've specified two arguments with the same destination, foo. This means that argparse will parse the first one, assign it to the attribute foo and then parse the second one and assign it to the attribute foo again, overwriting the previous one. So you only see the second one, but the first one wasn't ignored. If you didn't want them to overwrite the same attribute, you either need to declare them as action=append so that they both add to the same attribute, or you need to declare them with different destinations (and use metavar=foo if you want them to display the same way). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15271 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15125] argparse: positional arguments containing - in name not handled well
Steven Bethard steven.beth...@gmail.com added the comment:
I'm sympathetic to the idea that '-' should be translated similarly for
optional and positional arguments, but as you've noted, it would be a risky
patch because it's already possible for people to use getattr on hyphenated
arguments. So I think this isn't possible without a long deprecation process
first.
But patching the module to allow explicitly setting dest via keyword
argument shouldn't hurt anybody.
I agree that it wouldn't hurt anybody. If you can find a way to do this, feel
free to provide a patch.
However, the correct way to have one name for the attribute (i.e. dest=) and
one name for the help (i.e. metavar=) is to use the metavar argument like so:
parser.add_argument('positional_args', metavar='positional-args')
That said, this is not the first time I've seen someone run into this problem.
I think the documentation could be improved in a few ways:
(1) In the name or flags section, describe how the flags (for optional
arguments) are translated into both a default dest (stripping initial '-' and
converting '-' to '_') and into a default metavar (stripping initial '-' and
uppercasing). Part of this is in the dest and metavar documentation, but
probably belongs up in the name or flags documentation. Add cross-references
to dest and metavar sections.
(2) In the name or flags section, describe how the name (for positional
arguments) are translated into the same default dest and metavar (no string
munging at all). Again, move stuff from the dest and metavar sections as
necessary. Add cross-references to dest and metavar sections.
(3) In the dest section and somewhere in the parse_args section, describe
how getattr can be used to get attributes whose names aren't valid Python
identifiers. Maybe cross-reference this section from the edits in (2).
--
assignee: - docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15125
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11176] give more meaningful argument names in argparse documentation
Steven Bethard steven.beth...@gmail.com added the comment: Thanks for working on this! I think keeping the first example as simple is possible is probably a good idea. And I didn't have time to read through the whole patch, but as far as I went, the pizza examples looked great. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15336] Argparse required arguments incorrectly displayed as optional arguments
Changes by Steven Bethard steven.beth...@gmail.com: -- resolution: - duplicate status: open - closed superseder: - argparse: Default Help Message Lists Required Args As Optional ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15336 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under optional arguments
Steven Bethard steven.beth...@gmail.com added the comment: I'm changing the title because I keep seeing duplicates. Documentation patches still welcome! -- title: argparse: Default Help Message Lists Required Args As Optional - argparse required arguments displayed under optional arguments versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15327] Argparse: main arguments and subparser arguments indistinguishable
Steven Bethard steven.beth...@gmail.com added the comment:
I don't think there's any easy way for argparse to automatically do what you
want. However, there's a simple workaround - just use the dest= argument and
specify two different destinations:
parser = argparse.ArgumentParser()
parser.add_argument('--verbose', action='store_true', dest='verbose_main')
subparsers = parser.add_subparsers(help='command', dest='command')
cmd1_parser = subparsers.add_parser('command')
cmd1_parser.add_argument('--verbose', action='store_true',
dest='verbose_sub')
parser.parse_args(['command', '--verbose'])
Namespace(command='command', verbose_main=False, verbose_sub=True)
parser.parse_args(['--verbose', 'command'])
Namespace(command='command', verbose_main=True, verbose_sub=False)
Closing as a wontfix, but feel free to reopen if you want to provide a patch
for something.
--
resolution: - wont fix
status: open - closed
versions: -Python 2.7, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15327
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15428] add Name Collision section to argparse docs
New submission from Steven Bethard steven.beth...@gmail.com: Several bugs (e.g. Issue 15327 and Issue 15271) have been filed suggesting that people aren't really clear on how argparse handles argument name collisions or how they can get it to do what they want. I think these problems could probably be solved by a Name Collision section (or something like that) in the argparse documentation. It would give a few example problems and show how to resolve them. Some things to include: * What happens when two arguments have the same dest (Issue 15271), with solutions including action='append' or different dest= values combined with identical metavar= values. * What happens when a parser and a sub-parser share some of the same argument names (Issue 15327), with solutions including specifying different dest= values for the parser and sub-parser * A brief mention and cross-reference to the conflict_handler section. -- assignee: docs@python components: Documentation messages: 166185 nosy: bethard, docs@python priority: normal severity: normal status: open title: add Name Collision section to argparse docs versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15428 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15327] Argparse: main arguments and subparser arguments indistinguishable
Steven Bethard steven.beth...@gmail.com added the comment: If you'd like to help improve the documentation so that the workaround for your problem is more obvious, please contribute to Issue 15428. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15327 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15271] argparse: repeatedly specifying the same argument ignores the previous ones
Steven Bethard steven.beth...@gmail.com added the comment: I'm going to close this issue, since argparse is doing what you've asked it to, even if that wasn't what you expected. But I think the documentation for this kind of thing could be improved. If you'd like to help document the workaround for your problem that I described, please contribute to Issue 15428. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15271 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13720] argparse print_help() fails if COLUMNS is set to a low value
Steven Bethard steven.beth...@gmail.com added the comment: Definitely a bug here. Attached is a patch and a test, based on Russell Sim's suggestion, that should fix it. -- keywords: +patch versions: +Python 3.4 Added file: http://bugs.python.org/file26486/13720.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13922] argparse handling multiple -- in args improperly
Steven Bethard steven.beth...@gmail.com added the comment: This patch looks like the right fix to me. The tests look good too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14365] argparse: subparsers, argument abbreviations and ambiguous option
Steven Bethard steven.beth...@gmail.com added the comment: I think the real fix needs to search recursively though all subparsers. Here's a first draft of a patch that does this. I believe your sample code works after this patch. I don't have the time to turn your bug report into proper test (and add a test for the recursive bit), but hopefully this is enough to let someone else finish up fixing this bug. And yes, your dirty hack was still helpful in putting this together. ;-) -- keywords: +patch Added file: http://bugs.python.org/file26466/subparser_optionals.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14365 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14391] misc TYPO in argparse.Action docstring
Steven Bethard steven.beth...@gmail.com added the comment: The patch supplied was in reverse, but the bug report was correct. You can't pass type=string since there's no string callable, only a str callable. The docstring is confusing because the quotes make it looks like we mean the string 'str', when we actually mean the callable 'str'. Maybe they should be `str` or ``str``? Not sure what the syntax for code, not string literals, is for docstrings. Anyway, this should be an easy fix for a doc person. -- keywords: +easy resolution: out of date - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14391 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14392] type=bool doesn't raise error in argparse.Action
Steven Bethard steven.beth...@gmail.com added the comment:
I can't find anywhere in the documentation where type=bool, type=unicode or
type=long are disallowed. They shouldn't be disallowed. If you want to pass
type=bool, argparse should not stop you. And it currently doesn't:
parser = argparse.ArgumentParser()
parser.add_argument('foo', type=bool)
parser.parse_args([''])
Namespace(foo=False)
parser.parse_args(['x'])
Namespace(foo=True)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14392
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14449] argparse optional arguments should follow getopt_long(3)
Steven Bethard steven.beth...@gmail.com added the comment: I don't think this is going to change. It's basically a consequence of having a unified handling of nargs='?', nargs='*', nargs='+', etc. These will all consume as many arguments as they can, and argparse doesn't distinguish between arguments that are concatenated to options and arguments that aren't. (And you couldn't concatenate a whole '+' style argument to the option anyway.) If you really want getopt-style parsing instead, the getopt module is still available. ;-) -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14449 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14504] Suggestion to improve argparse's help messages for store_const
Steven Bethard steven.beth...@gmail.com added the comment: Special casing the formatting of 'store_const' makes me nervous because formatting is already complicated and it doesn't know anything about action types. But feel free to propose a patch! In the meantime: - propagate the default to all the options You can, of course, do this manually, by specifying default in each of them. And if you use formatter_class=ArgumentDefaultsHelpFormatter, you'll get the defaults in the usage message. - group the keywords that have the same destination together (?) - place the default option first (?) You can achieve both of these by just adding the options in the order that you want them displayed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13824] argparse.FileType opens a file and never closes it
Steven Bethard steven.beth...@gmail.com added the comment: So I generally agree that FileType is not what you want for anything but quick scripts that can afford to either leave a file open or to close stdin and/or stdout. However, quick scripts are an important use case for argparse, so I don't think we should get rid of FileType. What should definitely happen: * Someone should add some documentation explaining the risks of using FileType (e.g. forgetting to close the file, or closing stdin/stdout when you didn't mean to). What could potentially happen if someone really wanted it: * Someone could create a safe replacement, e.g. a FileOpenerType that returns an object with open() and close() methods that do the right things (or whatever API makes sense). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Steven Bethard steven.beth...@gmail.com added the comment: The patch looks good to me. I've updated it for trunk and to include Mike Meyer's additional test. All argparse tests pass. Anyone who's able to commit and backport, please do. (I should be able to commit myself, but it's now been too long and my SSH key seems to no longer work. I'll eventually get this sorted out, but as you may have noticed, I don't have much time for argparse these days, so best not to wait on me.) -- Added file: http://bugs.python.org/file26467/py3k-argparse-call-type-function-once-v5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12353] argparse cannot handle empty arguments
Steven Bethard steven.beth...@gmail.com added the comment: Yes, the original patch looks fine to me. I applied and tested it, and it works as expected. Please go ahead and apply. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13966] Add disable_interspersed_args() to argparse.ArgumentParser
Steven Bethard steven.beth...@gmail.com added the comment: The argparse changes and tests look good. The new method needs to be documented. You can see some other things (e.g. Misc/NEWS) that also need to be updated by running make patchcheck as described here: http://docs.python.org/devguide/patch.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13966 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11807] Documentation of add_subparsers lacks information about parametres
Steven Bethard steven.beth...@gmail.com added the comment: Looks good. There was one typo in parametres that I've fixed. Should be ready to apply. -- Added file: http://bugs.python.org/file26469/11807_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13818] argparse: -h listening required options under optional arguments
Changes by Steven Bethard steven.beth...@gmail.com: -- resolution: - duplicate status: open - closed superseder: - argparse: Default Help Message Lists Required Args As Optional ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9625] argparse: Problem with defaults for variable nargs when using choices
Steven Bethard steven.beth...@gmail.com added the comment: I agree that this looks like a bug. I think the fix is something like the attached patch, but it needs some tests to make sure that it fixes your problem. -- keywords: +patch Added file: http://bugs.python.org/file26471/issue9625.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9625 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14856] argparse: creating an already defined subparsers does not raises an exception
Steven Bethard steven.beth...@gmail.com added the comment: Yeah, overwriting the existing parser is probably not typically what the user intended. However, I could see someone doing this if, say, they had a parser designed by another module writer, and they wanted to use it but just change one of the sub-parsers or something like that. But a set_parser method would probably make more sense for this use case than add_parser. I guess my recommendation is to add a set_parser method that replaces the old parser (like add_parser does now), and then issue deprecation warnings in add_parser if a parser with the given name is present (like the patch does, but with deprecation warnings instead of exceptions). We could then turn the warnings into errors in a few releases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13922] argparse handling multiple -- in args improperly
Steven Bethard steven.beth...@gmail.com added the comment: Ok, I agree - I'm fine with it as a bugfix. Depending on the removal of extra -- strings would be pretty crazy anyway. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14364] Argparse incorrectly handles '--'
Steven Bethard steven.beth...@gmail.com added the comment: I just tried this with grep's -e and --regexp: $ cat temp.txt a--b cdef $ grep -e-- -v temp.txt cdef $ grep --regexp=-- -v temp.txt cdef $ grep -e -- -v temp.txt cdef $ grep --regexp -- -v temp.txt cdef And with diff's -I and --ignore-matching-lines: $ cat temp2.txt cdef a--b $ diff temp.txt temp2.txt 1d0 a--b 2a2 a--b $ diff -I-- temp.txt temp2.txt $ diff -I -- temp.txt temp2.txt $ diff --ignore-matching-lines -- temp.txt temp2.txt $ diff --ignore-matching-lines=-- temp.txt temp2.txt $ Note though that for options that don't take an argument, the -- is just removed: $ grep -v -- a temp.txt cdef $ diff -i -- temp.txt temp2.txt 1d0 a--b 2a2 a--b So I guess the unix rule is: if an option that takes an argument is followed by --, use that as the option's argument and continue parsing as usual. If an option that takes no argument is followed by --, then delete the -- and treat all following flags as positional arguments. Argparse can't follow this directly, because then people who are using -- to signal the end of an option with nargs=* would start getting -- included in that list. (And I know people have used -- this way for a while.) I guess my preference is what R. David Murray suggests: -- when part of an argument (i.e. not separated by spaces) is treated like any other characters, and only a lone -- signals the end of options (and is ignored otherwise). That would mean that both --test=-- and -t-- in your example would give you [--], and the other errors would stay as you saw them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14364 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13922] argparse handling multiple -- in args improperly
Steven Bethard steven.beth...@gmail.com added the comment: It prevents implementing parsers that pass strings on to another sub-parser or command. ... wouldn't you use 'parse_known_args' instead of 'parse_args' and pass the remaining arguments to the next script I'll just say again that the recommended way of passing arguments to another command is via nargs=argparse.REMAINDER. (Though you may still need -- if the first argument in the remainder is a flag shared by your parser, as Warren Turka pointed out.) I really want -- to mean treat everything else as non-optional arguments Yep, and that's what it's intended to mean, and what the documentation says: you can insert the pseudo-argument '--' which tells parse_args() that everything after that is a positional argument http://docs.python.org/library/argparse.html#arguments-containing It's therefore a bug if there's a '--' after the first '--', but it's not being treated as a positional argument. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14365] argparse: subparsers, argument abbreviations and ambiguous option
Steven Bethard steven.beth...@gmail.com added the comment: Yep. Closing as duplicate. -- resolution: - duplicate status: open - closed superseder: - argparse: allow abbreviation of sub commands by users ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14365 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14365] argparse: subparsers, argument abbreviations and ambiguous option
Steven Bethard steven.beth...@gmail.com added the comment: My mistake. I see that the error you're getting is a bad interaction between the option in the main parser and an ambiguous option in the subparser. -- resolution: duplicate - status: closed - open superseder: argparse: allow abbreviation of sub commands by users - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14365 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14365] argparse: subparsers, argument abbreviations and ambiguous option
Steven Bethard steven.beth...@gmail.com added the comment: The problem is basically that _parse_known_args calls _parse_optional to determine whether something is an optional or a positional. But _parse_optional only checks if arg_string in self._option_string_actions, that is, if the string can be found in the main parser actions. So either this method needs to check the subparser actions, or the if arg_string in self._option_string_actions stuff needs to be delayed until the subparser. Neither of these seems like a simple change, but I agree it's a bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14365 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
Steven Bethard steven.beth...@gmail.com added the comment: Hence, I conclude that, unless this was spelled out in the PEP and I missed it, that having such boundaries is a bug Practically speaking, we just can't change this because it will break existing argparse scripts. Argparse has had this behavior since 2006 when it was first released, and I guarantee you that many scripts expect and rely on this behavior. As I said earlier, the only reasonable solution is to document the current behavior more explicitly, and then add a new constructor parameter or method or something to enable the behavior you want. I looked a bit a guilherme's patch, and I think it's not really the right direction. We definitely shouldn't be modifying the action classes like _StoreAction. All changes should be within _parse_known_args. The parsing algorithm is so different for the proposed behavior, that I wonder if it wouldn't be easier to just create a new ArgumentParser subclass, ArgumentParserAllowingOptionalsInsidePositionals (or whatever), that just overrides _parse_known_args and rewrites it entirely. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
Steven Bethard steven.beth...@gmail.com added the comment: Thinking about it a bit more, it strikes me that maybe you could get the behavior you want by declaring two parsers, one with just optionals, and one with just positionals. Then: optional_args, remaining_args = optionals.parse_known_args() args = positionals.parse_args(remaining_args) vars(args).update(vars(optional_args)) Basically, you first parse out all the optional arguments, then you parse out the positional arguments from what's left after the optional arguments are stripped out. This approach seems to work for your t14.py. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
Steven Bethard steven.beth...@gmail.com added the comment: Actually, that could be even simpler: args, remaining_args = optionals.parse_known_args() args = positionals.parse_args(remaining_args, args) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
Steven Bethard steven.beth...@gmail.com added the comment: optparse, which argparse attempts to replace, permitted positional arguments to be intermixed with optional arguments Sure, but optparse didn't actually parse positional arguments - it just threw them into a bag, and then you had to group them and convert them however you wanted afterwards. Argparse, instead, was designed to let you specify the groups of positional arguments. Your situation is a little different because you just want to throw all the positional arguments into a bag again. Not that there's anything wrong with that - it's just not the primary use case argparse had in mind. The only definition of positional parameters I could find... Yeah, it looks like there's no good documentation on positional vs. optional parameters. Somewhere obvious, perhaps right at the beginning of the add_argument() documentation, there should probably be something like: Argparse groups the command line argument strings into two types of groups: optional arguments, which are a sequence of command line strings that begin with a flag like -v or --verbose, and positional arguments, which are a sequence of command line strings that do not begin with a flag. The add_argument() method allows you to specify how many command line strings each of your optional or positional arguments should consume, how those strings should be converted into Python objects, etc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
Steven Bethard steven.beth...@gmail.com added the comment: This behavior is intentional - positional arguments must be sequential, not broken up with optional (flag) arguments between. So this is a documentation bug. Allowing positional arguments to be broken up with optional (flag) arguments between them would be a new feature. It would also break many current parsers, so it couldn't be turned on by default. A new constructor parameter or method or something would have to be added to ArgumentParser. Patches welcome. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14149] argparse usage model requires argument names to be python identifiers
Steven Bethard steven.beth...@gmail.com added the comment:
For optional flags like --foo-bar, argparse does munge the dest to foo_bar,
following optparse. For positional arguments, arpgarse doesn't munge things
this way, but if you want the argument named foo-bar in help messages and
foo_bar on the Namespace object, you just need to do something like:
add_argument('foo_bar', metavar='foo-bar', ...)
Perhaps the docs could make this clearer.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14149
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14149] argparse: Document how to use argument names that are not Python identifiers
Steven Bethard steven.beth...@gmail.com added the comment: making Namespace subscriptable This has been discussed before - see issue 11076. I prefer to keep Namespace as simple as possible. For subscripting, just use the standard Python idiom of vars as suggested in the docs: http://docs.python.org/library/argparse.html#the-namespace-object -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14149 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
Steven Bethard steven.beth...@gmail.com added the comment: Yes, the problem is in FileType.__call__ - the handling of '-' is pretty simplistic. Patches welcome. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14046] argparse: assertion failure if optional argument has square/round brackets in metavar
Steven Bethard steven.beth...@gmail.com added the comment: Yes, this is a known bug (Issue 11874). Patches welcome. -- resolution: - duplicate superseder: - argparse assertion failure with brackets in metavars ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14046 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14074] argparse allows nargs1 for positional arguments but doesn't allow metavar to be a tuple
Steven Bethard steven.beth...@gmail.com added the comment: Looks like the problem is that _format_action_invocation is not being as careful with the different possibilities for metavar as _format_args is. Patches welcome! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14074 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14075] argparse: unused method?
Steven Bethard steven.beth...@gmail.com added the comment: It's undocumented, and it begins with an underscore, but it would certainly be safer to deprecate it first. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Steven Bethard steven.beth...@gmail.com added the comment: I think adding a new formatter for man pages would be generally useful. Assuming someone provides a patch. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14102 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14103] argparse: add ability to create a bash_completion script
Steven Bethard steven.beth...@gmail.com added the comment: Yeah, the same issues have been discussed in Issue 4256. My feeling so far is that if there isn't one true format that argparse can produce and be useful to a wide variety of shells, then it's probably not functionality that belongs in Python core, and instead belongs on PyPI. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] argparse: provide a simple way to get a programmatically useful list of options
Steven Bethard steven.beth...@gmail.com added the comment: So it seems like what bash needs and what zsh needs are pretty different. My feeling so far is that if there isn't one true format that argparse can produce and be useful to a wide variety of shells, then it's probably not functionality that belongs in Python core, and instead belongs on PyPI. So I guess my recommended next step would be to have someone offer help to the maintainer of http://pypi.python.org/pypi/optcomplete to update it to support argparse as well. If and when optcomplete supports argparse, bash, zsh and whatever other common shells people are using, and when optcomplete has significant usage in the field, then we can consider integrating it into the Python stdlib. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14034] Add argparse howto
Steven Bethard steven.beth...@gmail.com added the comment: Oh ok. Sounds good then! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14034 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14034] Add argparse howto
Steven Bethard steven.beth...@gmail.com added the comment: I have no objections on adding a howto, and something like the attached patch would be fine with me (though I don't have time to review it in full and trust you to). You might want to coordinate with Issue 13850 a bit - they want a quick reference table before the first example (which would therefore mean before this howto which is replacing the first example). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14034 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14075] argparse: unused method?
Steven Bethard steven.beth...@gmail.com added the comment: Yeah, the intention was that you could just override _get_args in a subclass to get a better __repr__. I think these days all the argparse classes only have keyword arguments, so _get_args probably isn't necessary anymore. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Steven Bethard steven.beth...@gmail.com added the comment: The implementation looks along the right track. Now it just needs some tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13922] argparse handling multiple -- in args improperly
Steven Bethard steven.beth...@gmail.com added the comment: See nargs=argparse.REMAINDER for an approach that doesn't require that first '--': http://docs.python.org/library/argparse.html#nargs But yeah, removing more than one '--' is probably a bug. Fixing it would be a little backwards incompatible though. Is it possible that anyone actually depends on the behavior of consuming multiple '--' arguments? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13966] Add disable_interspersed_args() to argparse.ArgumentParser
Steven Bethard steven.beth...@gmail.com added the comment: The idea and patch seem okay to me. Needs tests though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13966 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13879] Argparse does not support subparser aliases in 2.7
Steven Bethard steven.beth...@gmail.com added the comment: This is a new feature, not a bug, so I think the correct fix is to change the 2.7 documentation, since at this point 2.7 can only get bugfixes, not new features. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13879 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13850] Summary tables for argparse add_argument options
Steven Bethard steven.beth...@gmail.com added the comment: Sounds like an excellent plan to me too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13685] argparse does not sanitize help strings for % signs
Steven Bethard steven.beth...@gmail.com added the comment: Eric's suggested doc fix looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13584] argparse doesn't respect double quotes
Steven Bethard steven.beth...@gmail.com added the comment: Closing then. Thanks for checking it again! -- assignee: - bethard resolution: - works for me stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13584 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13540] Document the Action API in argparse
Steven Bethard steven.beth...@gmail.com added the comment: Sorry about being out of contact (I'm flying back and forth between the US and the EU every 4-5 weeks right now), and thanks Terry for bringing this to my attention. Essentially, the API is: * The argument to action= must be a callable that accepts at least a dest and option_strings keyword arguments, and returns some object. The keyword arguments passed to this callable will be dest, option_strings, and whatever other keyword arguments were passed to add_argument(). * The object returned by the action= callable should have attributes dest, option_strings, default, type, required, help, etc. defined in essentially the same way as the add_argument() documentation. * The object returned by the action= callable should itself be callable, and should accept the arguments (self, parser, namespace, values, option_string=None). This method can do whatever it wants, but as you note, the typical approach is to invoke setattr(namespace, self.dest, ...) Now, all that said, the easiest way of creating a callable that returns an callable where both have the right signatures and the right attributes is to subclass argparse.Action. In fact, doing it any other way is probably crazy. I'm against changing the name of __call__ to invoke because it removes the possibility of defining an action as a function returning another function (which is currently possible), but I'm all for making the documentation strongly recommend subclassing argparse.Action. I would just say something like: You may also specify an arbitrary action by passing a subclass of :class:`argparse.Action`, or another callable object that implements the same interface. I wouldn't bother to go into more detail about implements the same interface - all sane people will just subclass Action. ;-) As to argparse.Action.__init__, hopefully the above bullet points make it clear that you must accept dest and option_strings, but what other keyword arguments you want to accept are up to you. Be sure to call the superclass __init__ to set any attributes that you didn't accept to appropriate default values. A simple example of accepting an additional keyword argument is the _VersionAction, which accepts a version keyword argument that the other actions don't accept. The current example of a custom action should probably define __init__ to show how this works. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13540 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13584] argparse doesn't respect double quotes
Steven Bethard steven.beth...@gmail.com added the comment: Can you submit some example code that shows this? I can't reproduce this with: -- temp.py -- import argparse parser = argparse.ArgumentParser() parser.add_argument(--ng, action=store_true) parser.add_argument(--INP) print(parser.parse_args()) -- $ python temp.py --ng --INP=Demo IO Namespace(INP='Demo IO', ng=True) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13584 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Steven Bethard steven.beth...@gmail.com added the comment: Could you add a test to verify that custom actions are still getting the converted values passed to their __call__? I suspect this may not be happening under the current patch - if that's the case, you may also need to add conversions in _get_values, where the lines look like value = action.default. Also, action.default == getattr(namespace, action.dest) should probably use is instead of ==. Other than that, the patch looks okay. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10772] Several actions for argparse arguments missing from docs
Steven Bethard steven.beth...@gmail.com added the comment: Looks good to me too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10772 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Steven Bethard steven.beth...@gmail.com added the comment: The ArgumentParser constructor is definitely only intended to be called with keyword arguments, so it's definitely a documentation bug that it doesn't say this. I haven't actually applied the patch, but the basic approach and wording look fine to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13271] When -h is used with argparse, default values that fail should not matter
Steven Bethard steven.beth...@gmail.com added the comment: I think http://bugs.python.org/issue12776, which delays type conversions on defaults should solve this problem, right? If you agree, could you add your code here as a test case to that issue and mark this as duplicate? (And yes, I agree this is a bug.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13271 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Steven Bethard steven.beth...@gmail.com added the comment: I'd feel more comfortable with the argparse fix if it were simply calling os.get_terminal_size(). I recommend that you: * Create a new issue called, say add os.get_terminal_size() proposing just the single method. * Add that issue to the Dependencies of this issue. Once that is fixed, then the argparse fix should be simple. -- versions: +Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12806] argparse: Hybrid help text formatter
Steven Bethard steven.beth...@gmail.com added the comment: As I understand it the current proposal is: * Wrap each paragraph separately * Don't wrap any lines indented by at least one additional space This sounds like a useful formatter. I would probably call it PargraphWrappingFormatter or something like that which is more descriptive than FlexiFormatter. Sadly, it can't be the default, since that would break backwards compatibility, but I'd certainly agree to an obvious note somewhere in the docs recommending the use of this formatter instead of the current default. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Steven Bethard steven.beth...@gmail.com added the comment: If you can make your patch relative to the cpython source tree, and add a couple tests, it will be easier to review. Thanks for working on this! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13023] argparse should allow displaying argument default values in addition to setting a formatter class
Steven Bethard steven.beth...@gmail.com added the comment: Your solution is actually the current recommended solution - mix together both classes that you want to combine and pass your subclass as the parameter. This should probably be documented somewhere (and tested more). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13023 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12713] argparse: allow abbreviation of sub commands by users
Steven Bethard steven.beth...@gmail.com added the comment: Modulo the comments already on the patch by others, this approach looks fine to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12686] argparse - document (and improve?) use of SUPPRESS with help=
Steven Bethard steven.beth...@gmail.com added the comment: Could you give some examples of bugs that you observed? Otherwise, this looks like a duplicate of issue 9349. The intention is that help=SUPPRESS should cause the given argument to not be displayed in the help message. If there are cases where that's not true, then it's definitely a bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12686 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11708] argparse: suggestion for formatting optional positional args
Steven Bethard steven.beth...@gmail.com added the comment: I agree that this is a bug in current argparse formatting. It might be a little difficult to fix though because the current option formatting handles arguments one at a time, and producing something like [arg1 [arg2]] requires some understanding of how arguments interact, which the formatter currently doesn't have. But patches are certainly welcome. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12284] argparse.ArgumentParser: usage example option
Steven Bethard steven.beth...@gmail.com added the comment: %(prog)s is available in epilog: -- temp.py -- import argparse epilog = \ Example usage: %(prog)s option1 option2 parser = argparse.ArgumentParser( formatter_class=argparse.RawTextHelpFormatter, epilog=epilog) parser.parse_args() -- $ python temp.py -h usage: temp.py [-h] optional arguments: -h, --help show this help message and exit Example usage: temp.py option1 option2 -- Did you need more than that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9938] Documentation for argparse interactive use
Steven Bethard steven.beth...@gmail.com added the comment: Looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11839] argparse: unexpected behavior of default for FileType('w')
Steven Bethard steven.beth...@gmail.com added the comment: I think Issue 12776, which delays type conversions on defaults, should solve this problem, right? If you agree, could you add your code here as a test case to that issue and mark this as duplicate? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11874] argparse assertion failure with brackets in metavars
Steven Bethard steven.beth...@gmail.com added the comment: I agree this is a bug. The patch needs to add unit tests that make sure metavars with [] work as expected. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
