Message391339
Thanks for the context Paul. I didn't think to look in the tracker for an existing issue, sorry!
I'm not sure if documenting the requirement is sufficient or something that a user would go towards with the error as it is.
I _might_ suggest throwing an error if dest/metavar isn't provided when required is true but that would probably only work on creating the sub parser and not if setting attributes as I saw some tests doing.
If an error is thrown I'd expect it to be where I placed the default name and it to basically say sub parser has no name (and possibly suggest setting dest or metavar).
I think both might be confusing to the end user and likely something that a user relying on argparse might not test but expect to work (I am in that camp except I tested it... I was only wondering what it said). That is why I went with filling out the default of "command" (I also checked only one sub parser was allowed so that wouldn't be too ambiguous). Initially I went with "subcommand" because "subparser" didn't seem to make sense for an end user, but I settled with command since that's what some tests were using for dest and I liked it. I had also thought of expanding to all the options as one of the comments had in the other issue, but required argument: {command1,command2,...} looked a little funny and was less obvious what it meant since it could also looked like N arguments were missing and being represented in a collapsed representation. |
|
Date |
User |
Action |
Args |
2021-04-18 17:53:47 | terence.honles | set | recipients:
+ terence.honles, rhettinger, paul.j3 |
2021-04-18 17:53:47 | terence.honles | set | messageid: <1618768427.26.0.0726977835971.issue43874@roundup.psfhosted.org> |
2021-04-18 17:53:47 | terence.honles | link | issue43874 messages |
2021-04-18 17:53:46 | terence.honles | create | |
|