Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Handle no arguments when using sub-commands in argparse #99735

Open
ppaez opened this issue Nov 23, 2022 · 2 comments
Open

Handle no arguments when using sub-commands in argparse #99735

ppaez opened this issue Nov 23, 2022 · 2 comments
Labels
docs Documentation in the Doc dir

Comments

@ppaez
Copy link
Contributor

ppaez commented Nov 23, 2022 •
edited by bedevere-bot

Documentation

The example that shows the use of sub-commands and set_defaults to dispatch a function for each sub-command, fails when there are no command line arguments:

AttributeError: 'Namespace' object has no attribute 'func'

A pull request is provided that adds one line to handle that case and an explanation in the documentation.

Linked PRs
@ppaez ppaez added the docs Documentation in the Doc dir label Nov 23, 2022
@ppaez ppaez changed the title Handle no arguments when using sub-commands Handle no arguments when using sub-commands in argparse Nov 23, 2022
@ppaez ppaez mentioned this issue Nov 23, 2022
Closed
@hpaulj
Copy link

hpaulj commented Dec 8, 2022

Originally subparsers were required, so this issue did not come up. Because of a patching oversight, they are now optional, and we had to add the required parameter. I think this example would be better handled with a

 subparsers = parser.add_subparsers(required=True)

Then we wouldn't have to define a func for the no-subparser case. Your patch works, but I think it adds too much to the text and example, detracting from the essence of what set_defaults adds.

Whether we use set_defaults or not, the Namespace will have different attributes depending on what subparser (or none) the user invokes. The post parsing code has to handle that issue in one way or the other.

@bedevere-bot bedevere-bot mentioned this issue Jan 10, 2023
Merged
@ppaez
Copy link
Contributor Author

ppaez commented Jan 10, 2023

I hadn't used the required=True parameter before. It is mentioned in the reference, but I didn't consider it. I also was not aware of those changes (bpo-9253 and bpo-26510), thanks for explaining them.

PR #100927 has been created with only that change.

hauntsaninja pushed a commit that referenced this issue Feb 19, 2023
@ppaez
gh-99735: Use required=True in argparse subparsers example (#100927)
6aab56f
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Feb 19, 2023
@ppaez @miss-islington
pythongh-99735: Use required=True in argparse subparsers example (pyt…
0288d9b 
…honGH-100927)

(cherry picked from commit 6aab56f)

Co-authored-by: Patricio Paez <nospam@pp.com.mx>
This was referenced Feb 19, 2023
Open
Open
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Feb 19, 2023
@ppaez @miss-islington
pythongh-99735: Use required=True in argparse subparsers example (pyt…
6f8c2be 
…honGH-100927)

(cherry picked from commit 6aab56f)

Co-authored-by: Patricio Paez <nospam@pp.com.mx>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
docs Documentation in the Doc dir
Projects
Argparse issues
Status: No status
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ppaez @hpaulj