Since this Issue and #522 are vaguely related, it might be good to work them together.

I just want to summarize the items from this issue as well as #522 and #523 so everyone is in agreement about what the desired behavior.

• #515 - For argparse commands, it currently incorrectly assumes all commands accept '-h' as the parameter to print help. If possible, try to generate the help output without making assumptions about the flag.
• #523 - When help_command() is present, always use that - ignore the argparse description for the command.
• #522 - If 2 commands share the same argparse object, and the description is not set, try to use the appropriate command's doc-string text. Right now it's just taking the first one.

Does that summarize everything?
@kmvanbrunt @xNinjaKittyx @faraazc @tleonhardt

That does a good job of summarizing my understanding for the desired behavior as it relates to the three Issues you mention.

• #515 I agree with your description. Just call print_help() on the correct parser, which may be a subparser if a subcommand is being called.

• #523 Always calling help_command() when dealing with an argparse command is a tricky one. The user would have to understand that the help command will be called for the top level command even if the user is actually running a subcommand. This kind of usage seems to be a misunderstanding of argparse. I would rather encourage users to learn the argparse API. For instance, they could easily override a parser's or subparser's print_help() command instead.

• #522 I still don't feel right about this one. It opens the door for filling up our argparse decorators with so many corner cases. I honestly believe reusing an argparse object like this is bad code. Either make a deep copy of the parser, which is supported on newer versions of Python, or create the parser using a function as I demonstrated in an earlier post.

I’m also OK with Kevin’s interpretation. I just want all features to work correctly as documented. If there are exceptions and/or gotchas, we need to make that abundantly clear in the documentation and examples.

Let me clarify my comments about #522. Calling it bad code is harsh. I only mean to caution that it can introduce unpredictability. Here is an example based on things I do in my own application.

Let's say I have a function called do_print() which uses a parser called print_parser. There are times when I need information from print_parser like its prog value to print an error message. There are also times when I might call another argparse-based command from do_print(). If I call the other command and it happens to use the same parser object, then that object will be altered when the function returns execution back to do_print(). The parser will now how a prog value matching the other command.

• #515 - agree with proposed fix
• #522 - I think that we shouldn't write workarounds to allow the same argparser to be used on multiple do_ methods. I agree with @kmvanbrunt that is introduces unpredictability.
• #523 - No preference as long as it's clearly documented either way

#523 - This one may cause an issue if a user types command -h
That won't go through our help function, so argparse will print its own usage statement. I suppose we could overwrite print_help() in with_argparser(). But that still wouldn't cover running command subcommand -h