You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Handle no arguments when using sub-commands in argparse #99735
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.
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.
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.
Activity
[-]Handle no arguments when using sub-commands[/-][+]Handle no arguments when using sub-commands in argparse[/+]hpaulj commentedon Dec 8, 2022
Originally
subparserswere required, so this issue did not come up. Because of a patching oversight, they are now optional, and we had to add therequiredparameter. I think this example would be better handled with aThen we wouldn't have to define a
funcfor the no-subparser case. Your patch works, but I think it adds too much to the text and example, detracting from the essence of whatset_defaultsadds.Whether we use
set_defaultsor 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.ppaez commentedon Jan 10, 2023
I hadn't used the
required=Trueparameter 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.
gh-99735: Use required=True in argparse subparsers example (#100927)
pythongh-99735: Use required=True in argparse subparsers example (pyt…
pythongh-99735: Use required=True in argparse subparsers example (pyt…
gh-99735: Use required=True in argparse subparsers example (GH-100927)
gh-99735: Use required=True in argparse subparsers example (GH-100927)
Merge branch 'main' into inlinecomp2
erlend-aasland commentedon Feb 21, 2023
Can we close this issue?
hauntsaninja commentedon Feb 21, 2023
Yes we can! The backports had a hiccup, but they're all done now
Merge branch 'main' into inlinecomp