On Thu, Jun 27, 2013 at 2:50 PM, Ethan Furman <et...@stoneleaf.us> wrote:
> > If the OP is writing an interactive shell, shouldn't `cmd` be used instead > of `argparse`? argparse is, after all, intended for argument parsing of > command line scripts, not for interactive work. > He _is_ using cmd. He's subclassed cmd.Cmd and trying to use argparse to handle argument parsing in the Cmd.precmd method to preprocess the user input. Let's say that one of the user's commands requires an integer but they give a float or a string by accident: I believe the OP wants ArgumentParser to pass the appropriate ArgumentError exception up to the calling routine rather than catching it and calling ArgumentParser.error(), thereby destroying information about the exception type and instead requiring him to rely on parsing the far less reliable error message (since it's reasonable to expect that kind of thing to change from version to version). This way his calling routine can indicate to the user what was wrong with the last command and soldier on without bailing out of the program (or doing something ugly like catching a SystemExit and parsing argparse's error message). As it stands now, ArgumentParser has only limited utility in this respect since all parsing errors result in a SystemExit exception being thrown. Having subclassed cmd.Cmd myself in one of my programs and written my own argument parsing class to service it, I can appreciate what the OP is trying to do (and it's clever IMO). While argparse was not specifically designed for what the OP is trying to do, it would satisfy his needs nicely except for the previously mentioned issue. An alternative is, of course, to simply subclass ArgumentParser and copy over all of the code that catches an ArgumentError to eliminate the internal exception handling and instead allow them to propagate the call stack. All the best, Jason
-- http://mail.python.org/mailman/listinfo/python-list
