Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #49344 > unrolled thread
| Started by | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| First post | 2013-06-27 11:50 -0700 |
| Last post | 2013-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.
Re: Why is the argparse module so inflexible? Ethan Furman <ethan@stoneleaf.us> - 2013-06-27 11:50 -0700
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-06-27 11:50 -0700 |
| Subject | Re: 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~
Back to top | Article view | comp.lang.python
csiph-web