classification
Title: Documentation for argparse interactive use
Type: enhancement Stage: needs patch
Components: Documentation, Library (Lib) Versions: Python 3.3, Python 3.4, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Sourav Singh, a_b, bethard, docs@python, ezio.melotti, jayt, merwok, paul.j3, r.david.murray, tanqazx, wolma, xuanji
Priority: normal Keywords: easy, patch

Created on 2010-09-24 14:31 by jayt, last changed 2017-05-24 19:45 by Sourav Singh.

Files
File name Uploaded Description Edit
issue9938.patch xuanji, 2011-04-27 10:24 review
issue9938_with_test.patch xuanji, 2011-05-29 13:11 review
Messages (16)
msg117287 - (view) Author: Jay T (jayt) Date: 2010-09-24 14:31
I want to create a custom interactive shell where I continually do 
parse_args.  Like the following: 
parser = argparse.ArgumentParser() 
command = raw_input() 
while(True): 
  args = parser.parse_args(shlex.split(command)) 
  # Do some magic stuff 
  command = raw_input() 
The problem is that if I give it invalid input, it errors and exits 
with a help message.

I learned from argparse-users group that you can override the exit method like the following:

class MyParser(ArgumentParser): 
  def exit(self, status=0, message=None): 
    # do whatever you want here 

I would be nice to have this usage documented perhaps along with best practices for doing help messages in this scenario.
msg121531 - (view) Author: Éric Araujo (merwok) * (Python committer) Date: 2010-11-19 15:18
Do you want to work on a patch?

(Aside: you may want to learn about the cmd and shlex modules for read-eval-print-loop programs :)
msg124116 - (view) Author: Tan Zong Xuan (tanqazx) Date: 2010-12-16 09:04
I am also trying to use argparse interactively, but in this case by combining it with the cmd module. So I'm doing something like below:

class MyCmd(cmd.Cmd):

    parser = argparse.ArgumentParser(prog='addobject')
    parser.add_argument('attribute1')
    parser.add_argument('attribute2')
    parser.add_argument('attribute3')

    def do_addobject(self, line):
        args = MyCmd.parser.parse_args(line.split())
        newobject = object(args.attribute1, args.attribute2, args.attribute3)
        myobjects.append(newobject)

I'm faced with the same problem that when given invalid input, parse_args exits the program completely, instead of exiting just to the Cmd shell. 

I have the feeling that this use case is sufficiently common such that it would be good if people did not have to override the exit method themselves, and instead an alternative to parse_args was provided that only raises exceptions for the surrounding code to handle rather than exiting the program entirely.
msg124128 - (view) Author: Éric Araujo (merwok) * (Python committer) Date: 2010-12-16 13:48
You can always catch SystemExit.
msg124219 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2010-12-17 15:58
In the short term, just catch the SystemExit.

In the slightly longer term, we could certainly provide a subclass, say, ErrorRaisingArgumentParser, that overrides .exit and .error to do nothing but raise an exception with the message they would have printed. We'd probably have to introduce a new Exception subclass though, maybe ArgumentParserExit or something like that.

Anyway if you're interested in this, please file a new ticket (preferably  with a patch). Regardless of whether we ever provide the subclass, we certainly need to patch the documentation to tell people how to override error and exit.
msg134549 - (view) Author: Xuanji Li (xuanji) Date: 2011-04-27 10:24
I don't think it's best to create a new subclass to throw an ArgumentParserExit exception; if I read the stack trace I'd see that an ArgumentError was thrown, then caught, then an ArgumentParserExit was thrown, which IMHO is confusing. In the current design, parse_known_errors catches an ArgumentError and then exits. I propose that the user be optionally allowed to turn off the handling of ArgumentError and to handle it himself instead through an exit_on_argument_error flag. 

Attached patch does this. Also I think this issue falls under component 'Lib' too.
msg136082 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-05-16 12:00
FWIW unittest had a similar issue and it's been solved adding an 'exit' argument to unittest.main() [0].

I think using an attribute here might be fine.
The patch contains some trailing whitespace that should be removed, also it might be enough to name the attribute "exit_on_error".
It should also include tests to check that the attribute is set with the correct default value and that it doesn't raise SystemExit when the attribute is False.

[0]: http://docs.python.org/library/unittest.html#unittest.main
msg137184 - (view) Author: Xuanji Li (xuanji) Date: 2011-05-29 13:11
Updated previous patch with test cases and renamed exit_on_argument_error flag to exit_on_error.
msg149545 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2011-12-15 12:36
Looks good to me.
msg191973 - (view) Author: Andrew Berg (a_b) Date: 2013-06-28 01:28
What is the status of this? If the patch looks good, then will it be pushed into 3.4?
msg191974 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-06-28 01:41
It's great that this patch was provided.  Xuanji, can you submit a contributor agreement, please?

The patch is missing an update to the documentation.

(Really the patch should have been in a separate issue, as requested, since this one is about improving the documentation for the existing released versions.  I guess we'll have to open a new issue for updating the docs in the existing versions).
msg191975 - (view) Author: Andrew Berg (a_b) Date: 2013-06-28 04:26
The patch doesn't work for 3.3 (I think it's just because the line numbers are different), but looking over what the patch does, it looks like parse_known_args will return a value for args if there is an unrecognized argument, which will cause parse_args to call error() (it should raise ArgumentError instead).
msg191978 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2013-06-28 07:47
It doesn't look like xuanji has signed a CLA.

Should we create a new issue, and have someone else create a new patch, and let this issue just be about the docs?
msg191997 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-06-28 15:19
Yes, I think opening a new issue at this point might be a good idea.  The reason is that there are a changes either in place or pending in other issues that involve the parse_know_args code, so a new patch is probably required regardless.

I wish I had time to review and commit all the argparse patches, but so far I haven't gotten to them.  They are on my todo list somewhere, though :)
msg192147 - (view) Author: paul j3 (paul.j3) * Date: 2013-07-01 20:05
The exit and error methods are mentioned in the 3.4 documentation, but there are no examples of modifying them.

    16.4.5.9. Exiting methods
    ArgumentParser.exit(status=0, message=None)
    ArgumentParser.error(message)

test_argparse.py has a subclass that redefines these methods, though I think it is more complex than necessary.

    class ErrorRaisingArgumentParser(argparse.ArgumentParser):

In http://bugs.python.org/file30204/test_intermixed.py , part of http://bugs.python.org/issue14191 , which creates a parser mode that is closer to optparse in style, I simply use:

    def error(self, message):
        usage = self.format_usage()
        raise Exception('%s%s'%(usage, message))
    ArgumentParser.error = error

to catch errors.

https://github.com/nodeca/argparse a Javascript port of argparse, adds a 'debug' option to the ArgumentParser, that effectively redefines this error method.  They use that extensively in testing.

Another approach is to trap the sysexit.  Ipython does that when argparse is run interactively.

Even the simple try block works, though the SystemExit 2 has no information about the error.

    try:
        args = parser.parse_args('X'.split())
    except SystemExit as e:
        print(e)

Finally, plac ( https://pypi.python.org/pypi/plac ) is a pypi package that is built on argparse.  It has a well developed interactive mode, and integrates threads and multiprocessing.
msg294384 - (view) Author: Sourav Singh (Sourav Singh) Date: 2017-05-24 19:45
I would like to send a patch for the issue. How do I start
History
Date User Action Args
2017-05-24 19:45:11Sourav Singhsetnosy: + Sourav Singh
messages: + msg294384
2016-11-28 10:27:09wolmasetnosy: + wolma
2015-05-06 17:52:11r.david.murraylinkissue24070 dependencies
2015-02-25 04:18:52ethan.furmansetnosy: - ethan.furman
2013-07-01 20:05:20paul.j3setnosy: + paul.j3
messages: + msg192147
2013-06-28 15:19:51r.david.murraysetmessages: + msg191997
2013-06-28 07:48:00ethan.furmansetnosy: + ethan.furman
messages: + msg191978
2013-06-28 04:26:24a_bsetmessages: + msg191975
2013-06-28 01:41:47r.david.murraysetversions: + Python 3.4, - Python 3.2
nosy: + r.david.murray

messages: + msg191974

stage: needs patch
2013-06-28 01:28:12a_bsetnosy: + a_b
messages: + msg191973
2011-12-15 12:36:04bethardsetmessages: + msg149545
2011-05-29 13:11:28xuanjisetfiles: + issue9938_with_test.patch

messages: + msg137184
2011-05-16 12:00:21ezio.melottisetnosy: + ezio.melotti

messages: + msg136082
versions: + Python 3.3
2011-04-27 10:24:26xuanjisetfiles: + issue9938.patch
keywords: + patch
messages: + msg134549

components: + Library (Lib)
2010-12-19 13:25:05xuanjisetnosy: + xuanji
2010-12-17 15:58:02bethardsetnosy: bethard, merwok, docs@python, jayt, tanqazx
messages: + msg124219
2010-12-16 13:48:35merwoksetnosy: bethard, merwok, docs@python, jayt, tanqazx
messages: + msg124128
2010-12-16 09:04:50tanqazxsetnosy: + tanqazx
messages: + msg124116
2010-11-19 15:18:14merwoksetkeywords: + easy
nosy: + merwok
messages: + msg121531

2010-09-24 20:29:40bethardsetnosy: + bethard

versions: + Python 3.2
2010-09-24 14:31:29jaytcreate