Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!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; 'scripts': 0.03; 'interfaces': 0.04; 'argument': 0.05; 'exception.': 0.09; 'feature.': 0.09; 'lines.': 0.09; 'optparse': 0.09; 'override': 0.09; 'parsing': 0.09; 'scripts,': 0.09; 'subject:Why': 0.09; 'subject:module': 0.09; 'cc:addr:python-list': 0.11; 'thread': 0.14; 'cc:name:python list': 0.16; 'choice,': 0.16; 'cmd': 0.16; 'libraries.': 0.16; "method's": 0.16; 'simpson': 0.16; 'subclass': 0.16; 'subject:argparse': 0.16; 'to:addr:python.list': 0.16; 'to:addr:tim.thechases.com': 0.16; 'to:name:tim chase': 0.16; 'write,': 0.16; 'exception': 0.16; 'wrote:': 0.18; 'library': 0.18; 'all,': 0.19; 'module': 0.19; 'thu,': 0.19; 'command': 0.22; 'cc:addr:python.org': 0.22; 'error': 0.23; 'parse': 0.24; 'recognize': 0.24; "shouldn't": 0.24; 'cc:2**0': 0.24; 'script': 0.25; '>': 0.26; 'nearly': 0.26; 'header:In-Reply-To:1': 0.27; 'raise': 0.29; 'tim': 0.29; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'work.': 0.31; 'gives': 0.31; 'code': 0.31; 'chase': 0.31; 'invoke': 0.31; 'raised': 0.31; 'routine': 0.31; 'seemingly': 0.31; 'this.': 0.32; 'figure': 0.32; 'beginning': 0.33; 'older': 0.33; 'subject:the': 0.34; 'problem': 0.35; 'received:google.com': 0.35; 'add': 0.35; 'there': 0.35; 'combination': 0.36; 'library.': 0.36; 'method': 0.36; 'subject:?': 0.36; 'behind': 0.37; 'too': 0.37; 'being': 0.38; 'generic': 0.38; 'jason': 0.38; 'pm,': 0.38; 'ability': 0.39; 'bad': 0.39; 'lost': 0.61; 'new': 0.61; 'simply': 0.61; 'soon': 0.63; 'myself': 0.63; 'skip:n 10': 0.64; 'telling': 0.64; 'therefore,': 0.64; 'determine': 0.67; 'feeling': 0.68; 'default': 0.69; 'special': 0.74; 'behavior': 0.77; 'ethan': 0.84; 'furman': 0.84; 'preventing': 0.84; 'shell,': 0.91; 'choice.': 0.93; 'incredibly': 0.96; '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:to :cc:content-type; bh=FxnoQsnTqnJ33DQdwstLQiKel3N6nmK2WjjzMNJXhKo=; b=IVHYITeB9XKkqbbxIwrbMqEr3mclDIH5xI1y02peS6bTt75QREBnY3QiY5ARi3P70B D0Cks7Z7rHjhqVqwIhhaWFoQIqeGHRYGLNztiDH1014xQgzsofo3kO67buVnJYZ7z5QN G/jXrhqYznpyQTDxwYkaoq/0cg5IfTEIvFoIbkvuuZ0nO08FXn/rMAuiVS4Rh0ll1/En bbcR8Z8bDBEIMUQamNEql7TZUJnH1tNoGCAY2hjgk93GHqy/xWLR1TISq6zDErS207kT wiWNAdu67e1cokd7Af6jMdPYCW9QJoA1KbgyMj33Qu6h/jDcDii16JCof8051mRUeRUz m8TA== MIME-Version: 1.0 X-Received: by 10.50.128.36 with SMTP id nl4mr1600572igb.38.1372388339212; Thu, 27 Jun 2013 19:58:59 -0700 (PDT) In-Reply-To: <20130627192221.19949fa6@bigbox.christie.dr> References: <51CC897E.5000702@stoneleaf.us> <20130627230213.GA22992@cskk.homeip.net> <20130627192221.19949fa6@bigbox.christie.dr> Date: Thu, 27 Jun 2013 22:58:59 -0400 Subject: Re: Why is the argparse module so inflexible? From: Jason Swails To: Tim Chase Content-Type: multipart/alternative; boundary=089e0122a2aa73e62304e02e0fe3 Cc: python list 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: 118 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1372388348 news.xs4all.nl 15939 [2001:888:2000:d::a6]:46643 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:49358 --089e0122a2aa73e62304e02e0fe3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 27, 2013 at 8:22 PM, Tim Chase wrote: > On 2013-06-28 09:02, Cameron Simpson wrote: > > On 27Jun2013 11:50, 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. > > > > I invoke command line scripts interactively. There's no special > > case here. > > > > To add to the use case stats, I also subclass cmd and parse > > interactive command lines. I'm beginning to be pleased I'm still > > using Getopt for that instead of feeling I'm lagging behind the > > times. > > I too have several small utilities that use a combination of cmd.Cmd, > shlex.shlex(), and command-processing libraries. However, much like > Cameron's code using getopt, my older code is still using optparse > which gives me the ability to override the error() method's default > sys.exit() behavior and instead raise the exception of your choice. > There's nothing in argparse preventing this. There's still an ArgumentParser.error() method that you can override to raise an exception. The problem is that the original exception ArgumentParser raised when it hit a parsing error was lost as soon as the parsing routine caught said exception. Therefore, your new error() method must parse the message being passed to it in order to determine what error occurred and raise the corresponding exception of your choice, or simply settle with telling the user there was a generic argument parsing error that they have to figure out. Being a prolific user of argparse myself (I use it or optparse in nearly every script I write, although I greatly prefer argparse), I recognize it as an incredibly feature-packed, convenient, easy-to-use library. It's too bad that the utility of this library for non-commandline argument parsing is limited by a seemingly unnecessary feature. Of course, in RRsPy4k this whole module will just be replaced with "raise PyWart('All interfaces must be graphical')" and this whole thread will be moot. :) All the best, Jason --089e0122a2aa73e62304e02e0fe3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

<= /div>


On Thu, = Jun 27, 2013 at 8:22 PM, Tim Chase <python.list@tim.thechases.= com> wrote:
On 2013-06-28 09:02, Camer= on Simpson wrote:
> On 27Jun2013 11:50, Ethan Furman <ethan@stoneleaf.us> wrote:
> | If the OP is writing an interactive shell, shouldn't `cmd` be us= ed
> | instead of `argparse`? =A0argparse is, after all, intended for
> | argument parsing of command line scripts, not for interactive
> work.
>
> I invoke command line scripts interactively. T= here's no special
> case here.
>
> To add to the use case stats, I also subclass = cmd and parse
> interactive command lines. I'm beginning to be pleased I'm sti= ll
> using Getopt for that instead of feeling I'm lagging behind the > times.

I too have several small utilities that use a combination of cmd.Cmd,=
shlex.shlex(), and command-processing libraries. =A0However, much like
Cameron's code using getopt, my older code is still using optparse
which gives me the ability to override the error() method's default
sys.exit() behavior and instead raise the exception of your choice.

There's nothing in argparse preventing this. =A0There's still = an ArgumentParser.error() method that you can override to raise an exceptio= n. =A0The problem is that the original exception ArgumentParser raised when= it hit a parsing error was lost as soon as the parsing routine caught said= exception.

Therefore, your new error() = method must parse the message being passed to it in order to determine what= error occurred and raise the corresponding exception of your choice, or si= mply settle with telling the user there was a generic argument parsing erro= r that they have to figure out.

Being a prolific user of arg= parse myself (I use it or optparse in nearly every script I write, although= I greatly prefer argparse), I recognize it as an incredibly feature-packed= , convenient, easy-to-use library. =A0It's too bad that the utility of = this library for non-commandline argument parsing is limited by a seemingly= unnecessary feature.

Of course, in RRsPy4k this w= hole module will just be replaced with "raise PyWart('All interfac= es must be graphical')" and this whole thread will be moot. :)

All the best,
Jason
=
--089e0122a2aa73e62304e02e0fe3--