@xNinjaKittyx Thank you for reporting this issue. It is certainly undesirable for one command to inadvertently pick up the docstring help from another command.

@anselor @kmvanbrunt Would either of you want to take a look at this? It sounds up your alley.

Since this Issue and #515 are somewhat related, it might be a good idea to work on a solution for them at the same time.

This isn't really a cmd2 or argparse issue. The same parser object is being passed into both function wrappers. Even if you did change the description in between the function declarations, both functions would still print the new description because the same object is being altered.

A deep copy of the parser needs to be made for each function you wish to use it with before the description gets set. I tried this in Python 3.5 on Debian 9 and didn't have much luck.

I received lots of exceptions doing this with an ACArgumentParser object:
parser_copy = copy.deepcopy(orig_parser)

I found a decent workaround if deepcopy doesn't work. Write a function to create and return the type of parser you want to reuse. Then call it for each function being wrapped.

def make_parser():
    new_parser = argparse.ArgumentParser()
    new_parser.add_argument('-s', '--something', type=str, help='some argument')
    return new_parser

class SomeClass(Cmd):
    @with_argparser(make_parser())
    def do_foo(self, opts):
        """This is foo docstring"""
        pass

    @with_argparser(make_parser())
    def do_bar(self, opts):
        """This is bar docstring"""
        pass

Sure, that seems like a reasonable workaround.

The way I originally was thinking of was something like this:

def with_argparser(argparser: argparse.ArgumentParser) -> Callable:
    """A decorator to alter a cmd2 method to populate its ``args`` argument by parsing arguments
    with the given instance of argparse.ArgumentParser.

    :param argparser: argparse.ArgumentParser - given instance of ArgumentParser
    :return: function that gets passed parsed args
    """
    import functools

    # noinspection PyProtectedMember
    def arg_decorator(func: Callable):
        if argparser.description is None:
            argparser.init_with_description = False
        @functools.wraps(func)
        def cmd_wrapper(instance, cmdline):
            lexed_arglist = parse_quoted_string(cmdline)
            try:
                # argparser defaults the program name to sys.argv[0]
                # we want it to be the name of our command
                argparser.prog = func.__name__[3:]
                # If the description has not been set, then use the method docstring if one exists

                if not argparser.init_with_description and func.__doc__:
                    argparser.description = func.__doc__
                args = argparser.parse_args(lexed_arglist)
            except SystemExit:
                return
            else:
                return func(instance, args)

        if func.__doc__:
            setattr(cmd_wrapper, HELP_SUMMARY, func.__doc__)

        cmd_wrapper.__doc__ = argparser.format_help()

        # Mark this function as having an argparse ArgumentParser
        setattr(cmd_wrapper, 'argparser', argparser)

        return cmd_wrapper

    return arg_decorator

Where the function name and doc string were dynamically changed based on the command.
Your suggestion is okay, and it means each command has to have its own unique argparser object, which is totally reasonable.

Feel free to close based on your decision.

I'm inclined to handle it inside with_argparser rather than creating a separate argparser per command. On phone right now so difficult to look at this specific implementation. I was pretty sure that this could be done without making multiple argparser objects.

The solution proposed by @xNinjaKittyx does work. However, I'm not sure it sets a good precedent. Argparse has many parameters that a user could want overridden between commands (ex: usage and epilog). How many cases do the decorators need to handle?

@kmvanbrunt For whatever its worth, the inability to deepcopy an argparse.ArgumentParser is a known issue and has been fixed in Python 3.7. Unfortunately, I don't believe there are any plans to back port that fix to Python 3.5 or 3.6.

I would prefer for cmd2 to handle correct behavior within the argparse-based decorators if it is reasonable. If not, then we need to add a big bold glaring warning to the documentation telling end users that each command needs a unique ArgumentParser.

Then general consensus among the cmd2 core maintainers is that it would be a bad idea to try to write workarounds to allow the same argparser to be used on multiple do_ methods because this could introduce unpredictability if we didn't design and implement this perfectly.

For now we will document that a separate instance of an argparser needs to be used for each command. We should make sure to also demonstrate best practices. Perhaps we could keep track of id's of all argparsers used so far and disallow one to be used again, but maybe that would be overkill?

In the future if cmd2 gets to the point of only supporting Python 3.7 or newer, then we could revisit this Issue because then we would be able to make a deepcopy of an argparse.ArgumentParser.