Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder5.xlned.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Thu, 27 Jun 2013 11:50:38 -0700
From: Ethan Furman <ethan@stoneleaf.us>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Why is the argparse module so inflexible?
References: <51CC35F4.3040609@gmail.com> <kqhusi$je5$1@ger.gmane.org> <51CC8205.5060906@davea.name> <kqi0s8$a5d$1@ger.gmane.org>
In-Reply-To: <kqi0s8$a5d$1@ger.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3939.1372361841.3114.python-list@python.org>
Lines: 55
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:49344

On 06/27/2013 11:39 AM, Terry Reedy wrote:
> On 6/27/2013 2:18 PM, Dave Angel wrote:
>> On 06/27/2013 02:05 PM, Terry Reedy wrote:
>>> On 6/27/2013 8:54 AM, Andrew Berg wrote:
>>>> I've begun writing a program with an interactive prompt, and it needs
>>>> to parse input from the user.  I thought the argparse module would be
>>>> great for this,
>>>
>>> It is outside argparse's intended domain of application -- parsing
>>> command line arguments. The grammar for a valid string of command line
>>> arguments is quite restricted.
>>>
>>> Argparse is not intended for interactive processing of a domain-specific
>>> language (DSL). There are other parsers for that. But if the grammar for
>>> your DSL is restricted to what argparse can handle, using it is an
>>> interesting idea. But you need non-default usage for the non-default
>>> context.
>>>
>>>  > but unfortunately it insists on calling sys.exit() at
>>>> any sign of trouble instead of letting its ArgumentError exception
>>>> propagate so that I can handle it.
>>>
>>> When one tell argparse that something is *required*, that means "I do
>>> not want to see the user's input unless it passes this condition." After
>>> seeing an error message, the user can edit the command line and re-enter.
>>>
>>> If you do not mean 'required' in the sense above, do not say so.
>>> Catching SystemExit is another way to say 'I did not really mean
>>> required, in the usual mean of that term.'.
>>>
>>
>> That last sentence is nonsense.
>
> Not if you understand what I said.
>
>> If one is parsing the line the user  enters via raw_input(),
>
> input(), in 3.x
>
>> catching SystemExit so the program doesn't abort
>> is perfectly reasonable.  The user should be returned to his prompt,
>> which in this case is probably another loop through raw_input().
>
> Right, because 'required' means something a little different in the interactive context.
>
> I don't know if all the information in the original ArgumentError exception is transferred to the SystemExit exception.
> I expect not, and if so, and if multiple people are using argparse this way, it would be reasonable to request on the
> tracker that its current sys.exit behavior become default but optional in 3.4+. There might even be an issue already if
> one searched.

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.

--
~Ethan~