Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder5.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Sat, 29 Jun 2013 13:38:00 +0100
From: Marcin Szamotulski <mszamot@gmail.com>
To: python-list@python.org
Subject: Re: Why is the argparse module so inflexible?
References: <mailman.3924.1372337705.3114.python-list@python.org> <roy-57E318.09080527062013@70-1-84-166.pools.spcsdns.net> <51CC42E3.3070508@gmail.com> <mailman.3933.1372348963.3114.python-list@python.org> <51ccc190$0$29999$c3e8da3$5496439d@news.astraweb.com> <mailman.3974.1372469806.3114.python-list@python.org> <51ce708f$0$29999$c3e8da3$5496439d@news.astraweb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51ce708f$0$29999$c3e8da3$5496439d@news.astraweb.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3986.1372509508.3114.python-list@python.org>
Lines: 69
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:49416

On 05:28 Sat 29 Jun     , Steven D'Aprano wrote:
> On Fri, 28 Jun 2013 18:36:37 -0700, Ethan Furman wrote:
> 
> > On 06/27/2013 03:49 PM, Steven D'Aprano wrote:
> >>
> >> [rant]
> >> I think it is lousy design for a framework like argparse to raise a
> >> custom ArgumentError in one part of the code, only to catch it
> >> elsewhere and call sys.exit. At the very least, that OUGHT TO BE A
> >> CONFIG OPTION, and OFF BY DEFAULT.
> 
> [emphasis added]
> 
> >> Libraries should not call sys.exit, or raise SystemExit. Whether to
> >> quit or not is not the library's decision to make, that decision
> >> belongs to the application layer. Yes, the application could always
> >> catch SystemExit, but it shouldn't have to.
> > 
> > So a library that is explicitly designed to make command-line scripts
> > easier and friendlier should quit with a traceback?
> > 
> > Really?
> 
> Yes, really.
> 
> Tracebacks are not that unfriendly, generally speaking. In my experience, 
> the average non-technical person is no more confused and distressed by a 
> traceback extending over thirty lines than they are by a one line error 
> message. As the developer, I should see the tracebacks by default[1]. If 
> I want to suppress or simplify them, then I should take explicit steps to 
> do so, either by catching the exception and calling sys.exit myself, or 
> at least by setting a runtime config option to the library.
> 
> This also allows me to enable debugging in my app by showing tracebacks, 
> or disable it by hiding them. That should be my decision, not the 
> library. If the library catches exceptions then exits, throwing away 
> potentially useful information, that makes it difficult to debug anything 
> relying on the library.
> 
> I'm willing to concede that, just maybe, something like argparse could 
> default to "catch exceptions and exit" ON rather than OFF. 
> 
> 
> [1] There's something in the Zen of Python about that...
> 
> 
> -- 
> Steven
> -- 
>

Although I got confused at the first time I was using argparse (or
optparse which is now obsolte and also has this feature), I see the
value when you write scripts.  It is mostly annoying when playing with
it in a console, but there is a very easy (but partial) fix for that:
just subclass argparse.ArgumentParser:

import sys
class ArgumentParser(argparse.ArgumentParser):
    def  exit(self, status=0, message=None):
        if message:
            self._print_message(message, sys.stderr)

now the parser will not exit, though there is no ease fix to get the
traceback: self.exit() is called in various places sometimes inside
a try block.

Best regards,
Marcin http://mail.python.org/mailman/listinfo/python-list