Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #49344 > unrolled thread

Re: Why is the argparse module so inflexible?

Started byEthan Furman <ethan@stoneleaf.us>
First post2013-06-27 11:50 -0700
Last post2013-06-27 11:50 -0700
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Why is the argparse module so inflexible? Ethan Furman <ethan@stoneleaf.us> - 2013-06-27 11:50 -0700

#49344 — Re: Why is the argparse module so inflexible?

FromEthan Furman <ethan@stoneleaf.us>
Date2013-06-27 11:50 -0700
SubjectRe: Why is the argparse module so inflexible?
Message-ID<mailman.3939.1372361841.3114.python-list@python.org>
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~

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web