Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!weretis.net!feeder4.news.weretis.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'argument': 0.05; 'float': 0.07; 'nicely': 0.07; 'ugly': 0.07; 'string': 0.09; 'parsing': 0.09; 'propagate': 0.09; 'satisfy': 0.09; 'scripts,': 0.09; 'stack.': 0.09; 'subject:Why': 0.09; 'subject:module': 0.09; 'cc:addr:python-list': 0.11; 'cc:name:python list': 0.16; 'subclass': 0.16; 'subject:argparse': 0.16; 'systemexit': 0.16; 'thereby': 0.16; 'version).': 0.16; '\xa0this': 0.16; 'exception': 0.16; 'appropriate': 0.16; 'do,': 0.16; 'wrote:': 0.18; 'all,': 0.19; 'trying': 0.19; 'thu,': 0.19; 'written': 0.21; 'command': 0.22; 'issue.': 0.22; 'previously': 0.22; 'cc:addr:python.org': 0.22; 'error': 0.23; 'integer': 0.24; "shouldn't": 0.24; '(or': 0.24; 'cc:2**0': 0.24; 'handling': 0.26; 'pass': 0.26; 'header:In- Reply-To:1': 0.27; 'specifically': 0.29; 'errors': 0.30; 'message- id:@mail.gmail.com': 0.30; 'work.': 0.31; 'code': 0.31; '(since': 0.31; 'catching': 0.31; 'clever': 0.31; 'routine': 0.31; 'stands': 0.31; "user's": 0.31; 'class': 0.32; 'subject:the': 0.34; 'except': 0.35; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'version': 0.36; "he's": 0.36; 'doing': 0.36; 'method': 0.36; 'subject:?': 0.36; 'wrong': 0.37; 'being': 0.38; 'jason': 0.38; 'requiring': 0.38; 'handle': 0.38; 'pm,': 0.38; 'rather': 0.38; 'expect': 0.39; 'commands': 0.60; 'mentioned': 0.61; 'simply': 0.61; 'information': 0.63; 'kind': 0.63; 'myself': 0.63; 'believe': 0.68; 'respect': 0.70; 'ethan': 0.84; 'furman': 0.84; 'message).': 0.84; 'shell,': 0.91; 'to:none': 0.92; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=xhq9bJSVc5W1CYSIUfeHQl6iZ1SLyny6gUtoFlK1ngw=; b=f/zVEgh0kwuoFzJPLHaQzZIHMl8erve/JC6K1rX8O17Ytf6iYJk73AFYDKjI5JgAEW ZyPsL56zjv6IIpor2bPPL7x+qlDWloQURHqxpg9DCiKUWzdS5zJkC6bbBQK8RB6A0Uxn i4oqkoWVpN1ncI7JYv55yFgLsLx/0cZHEUyPNiTTnlAyetw5jB+jGUER/KEDh5bqL8cI rVggUhrwK34kY5gU/P0qgE+skSTjb21VTEER37GTs6VwyD0CIlQmjLAUrxaSt2wuQeFI D0aFlzoigl6XTdekkyf5OSWDB9EqoU8pI5IQX8nnSF0JU13GFi7hk/L/lXGx+y6fXkjY 6ZoA== MIME-Version: 1.0 X-Received: by 10.50.132.98 with SMTP id ot2mr643456igb.38.1372368600273; Thu, 27 Jun 2013 14:30:00 -0700 (PDT) In-Reply-To: <51CC897E.5000702@stoneleaf.us> References: <51CC35F4.3040609@gmail.com> <51CC8205.5060906@davea.name> <51CC897E.5000702@stoneleaf.us> Date: Thu, 27 Jun 2013 17:30:00 -0400 Subject: Re: Why is the argparse module so inflexible? From: Jason Swails Cc: python list Content-Type: multipart/alternative; boundary=047d7b2e3d7eeb9eb904e029763d X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 97 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1372368609 news.xs4all.nl 15911 [2001:888:2000:d::a6]:49158 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:49346 --047d7b2e3d7eeb9eb904e029763d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 27, 2013 at 2:50 PM, Ethan Furman 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 --047d7b2e3d7eeb9eb904e029763d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, J= un 27, 2013 at 2:50 PM, Ethan Furman <ethan@stoneleaf.us> w= rote:

If the OP is writing an interactive shell, shouldn't `cmd` be used inst= ead of `argparse`? =A0argparse is, after all, intended for argument parsing= of command line scripts, not for interactive work.

He _is_ using cmd. =A0He's subclassed cmd.Cmd and try= ing 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 belie= ve the OP wants ArgumentParser to pass the appropriate ArgumentError except= ion up to the calling routine rather than catching it and calling ArgumentP= arser.error(), thereby destroying information about the exception type and = instead requiring him to rely on parsing the far less reliable error messag= e (since it's reasonable to expect that kind of thing to change from ve= rsion to version). =A0This 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 parsin= g argparse's error message).

As it stands now, ArgumentParser has only limited= utility in this respect since all parsing errors result in a SystemExit ex= ception being thrown. =A0Having subclassed cmd.Cmd myself in one of my prog= rams and written my own argument parsing class to service it, I can appreci= ate what the OP is trying to do (and it's clever IMO). =A0While argpars= e was not specifically designed for what the OP is trying to do, it would s= atisfy 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 prop= agate the call stack.

All the best,
Jason
--047d7b2e3d7eeb9eb904e029763d--