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


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

Re: Why is the argparse module so inflexible?

Started byDave Angel <davea@davea.name>
First post2013-06-27 14:18 -0400
Last post2013-06-27 14:18 -0400
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? Dave Angel <davea@davea.name> - 2013-06-27 14:18 -0400

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

FromDave Angel <davea@davea.name>
Date2013-06-27 14:18 -0400
SubjectRe: Why is the argparse module so inflexible?
Message-ID<mailman.3937.1372357142.3114.python-list@python.org>
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.  If one is parsing the line the user 
enters via raw_input(), 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().

Or perhaps entering a bad password should blow the circuit breaker?

-- 
DaveA

[toc] | [standalone]


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


csiph-web