[issue38438] argparse "usage" overly-complex with nargs="*"

Raymond Hettinger added the comment: Bob, thanks for the suggestion. Brandt, thanks for the PR. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.7, Python 3.8 ___ Python tracker

[issue38438] argparse "usage" overly-complex with nargs="*"

Raymond Hettinger added the comment: New changeset a0ed99bca8475cbc82e9202aa354faba2a4620f4 by Raymond Hettinger (Brandt Bucher) in branch 'master': bpo-38438: Simplify argparse "star nargs" usage. (GH-17106) https://github.com/python/cpython/commit/a0ed99bca8475cbc82e9202aa354faba2a4620f4

[issue38438] argparse "usage" overly-complex with nargs="*"

Brandt Bucher added the comment: I went ahead and opened a PR, since it's been a month. -- ___ Python tracker ___ ___

[issue38438] argparse "usage" overly-complex with nargs="*"

Change by Brandt Bucher : -- keywords: +patch pull_requests: +16612 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17106 ___ Python tracker ___

[issue38438] argparse "usage" overly-complex with nargs="*"

Change by Callum Ward : -- nosy: +callumquick ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38438] argparse "usage" overly-complex with nargs="*"

Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38438] argparse "usage" overly-complex with nargs="*"

Eric V. Smith added the comment: I don't think it's any more precise. It just seems verbose and confusing to me, while conveying the same information. `[arg [arg ...]]` to me means "optionally, an arg followed by one or more optional args". While `[arg ...]` to me means "optionally, one

[issue38438] argparse "usage" overly-complex with nargs="*"

Brandt Bucher added the comment: For backward compatibility with 2 metavars, the two-name form should still be possible. Just pass metavar=("FOO", "FOO"). -- ___ Python tracker

[issue38438] argparse "usage" overly-complex with nargs="*"

Nick Timkovich added the comment: The `[arg [arg ...]]` feels a bit more formal to me, and I might prefer it in the example shown where the arg name is fairly short. That said, `man mv` shows something like: mv [OPTION]... [-T] SOURCE DEST mv [OPTION]... SOURCE... DIRECTORY mv

[issue38438] argparse "usage" overly-complex with nargs="*"

Raymond Hettinger added the comment: Bob, as OP you get first dibs on a PR. Brandt, you're next in line :-) -- ___ Python tracker ___

[issue38438] argparse "usage" overly-complex with nargs="*"

Brandt Bucher added the comment: I’m happy to write one. This seems like a pretty straightforward fix. -- ___ Python tracker ___

[issue38438] argparse "usage" overly-complex with nargs="*"

Raymond Hettinger added the comment: Bob, would like to create a PR? -- assignee: -> rhettinger ___ Python tracker ___ ___

[issue38438] argparse "usage" overly-complex with nargs="*"

Change by Karthikeyan Singaravelan : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38438] argparse "usage" overly-complex with nargs="*"

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38438] argparse "usage" overly-complex with nargs="*"

Eric V. Smith added the comment: I think [arg ...] would make sense. Removing 3.5 and 3.6, since they're in security only mode. Adding 3.9. -- nosy: +eric.smith versions: +Python 3.9 -Python 3.5, Python 3.6 ___ Python tracker

[issue38438] argparse "usage" overly-complex with nargs="*"

New submission from Bob Alexander : This program: import argparse ap = argparse.ArgumentParser() ap.add_argument("arg", nargs="*") ap.parse_args() Gives usage message: usage: help_complexity.py [-h] [arg [arg ...]] It's correct, but unnecessarily complex and challenging to the user. If I