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

Groups > comp.lang.python > #49342

Re: Why is the argparse module so inflexible?

Show key headers only | View raw

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

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Why is the argparse module so inflexible? Dave Angel <davea@davea.name> - 2013-06-27 14:18 -0400

csiph-web