Why use argparse rather than optparse?

Question

I noticed that the Python 2.7 documentation includes yet another command-line parsing module. In addition to getopt and optparse we now have argparse.

Why has yet another command-line parsing module been created? Why should I use it instead of optparse? Are there new features that I should know about?

Jerrine

Or maybe use none because since 2012 Python has an easy, powerful and really cool module for argument parsing called docopt. docopt.org – Palaeontology

try click it is wrapper around optparse. – Lichen

Answer 1

As of python 2.7, optparse is deprecated, and will hopefully go away in the future.

argparse is better for all the reasons listed on its original page (https://code.google.com/archive/p/argparse/):

• handling positional arguments
• supporting sub-commands
• allowing alternative option prefixes like + and /
• handling zero-or-more and one-or-more style arguments
• producing more informative usage messages
• providing a much simpler interface for custom types and actions

More information is also in PEP 389, which is the vehicle by which argparse made it into the standard library.

Unerring

A much simpler interface for custom types... but a more complex interface overall. I really do wonder why I even switched to optparse, because drumroll getopt will stay. Yup, no deprecation for that dinosaur. Sheeesh. – Mcquiston

The mention of "purity" of optparse in the PEP then later arguments about how complex it is to add on to makes it sound like it was coded to be as flexible as rock (poorly). – Klenk

The subcommands interface is poor. Default output is not useful and changing it is hard. – Duct

Note that code.google.com will go on Maintenance in few days. Differences with more details are available here: argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html – Loaf

Answer 2

Why should I use it instead of optparse? Are their new features I should know about?

@Nicholas's answer covers this well, I think, but not the more "meta" question you start with:

Why has yet another command-line parsing module been created?

That's the dilemma number one when any useful module is added to the standard library: what do you do when a substantially better, but backwards-incompatible, way to provide the same kind of functionality emerges?

Either you stick with the old and admittedly surpassed way (typically when we're talking about complicated packages: asyncore vs twisted, tkinter vs wx or Qt, ...) or you end up with multiple incompatible ways to do the same thing (XML parsers, IMHO, are an even better example of this than command-line parsers -- but the email package vs the myriad old ways to deal with similar issues isn't too far away either;-).

You may make threatening grumbles in the docs about the old ways being "deprecated", but (as long as you need to keep backwards compatibility) you can't really take them away without stopping large, important applications from moving to newer Python releases.

(Dilemma number two, not directly related to your question, is summarized in the old saying "the standard library is where good packages go to die"... with releases every year and a half or so, packages that aren't very, very stable, not needing releases any more often than that, can actually suffer substantially by being "frozen" in the standard library... but, that's really a different issue).

Pily

Admittedly, you can include argparse.py for python installations before 2.7 and not worry about backwards-incompatible changes. Extra thing to track, but it is still maintained outside of the standard library at argparse.googlecode.com – Souvenir

Argparse is substantially better only for some (niche?) uses. It's not really better in absolute terms, it's different. It can do things optparse can't, but it also has regressions. One example I just ran into: optparse handled "--" by default (not sure it did what this is supposed to do) while argparse doesn't know anything of it. – Mcquiston

For anyone coming to the above comment late, argparse has you set the prefix and the name, and most parsers are written as parser.add_argument('--long-opt', '-l',...); '--' is handled easily, and however you like. – Regenerator

@SilverbackNet: looks like you missed the point about '--'. For standard Unix commands arguments parsing, an occurence of '--' (by itself, not as a prefix) means what follows are not options any more even if they begin with dashes. – Demoralize

One could unbundle long-deprecated libraries from cpython. Large, important applications that couldn't migrate to the better, bundled replacement could just pull them from pypi, and everyone else would benefit from a smaller installation. – Acetophenetidin

Answer 3

The best source for rationale for a Python addition would be its PEP: PEP 389: argparse - New Command Line Parsing Module, in particular, the section entitled, Why aren't getopt and optparse enough?

Haggard

Answer 4

There are also new kids on the block!

• Besides the already mentioned deprecated optparse. [DO NOT USE]
• argparse was also mentioned, which is a solution for people not willing to include external libs.
• docopt is an external lib worth looking at, which uses a documentation string as the parser for your input.
• click is also external lib and uses decorators for defining arguments. (My source recommends: Why Click)
• python-inquirer For selection focused tools and based on Inquirer.js (repo)

If you need a more in-depth comparison please read this and you may end up using docopt or click. Thanks to Kyle Purdon!

Undesigning

while this is a worthwhile comment, it still is a comment more than an answer.. no downvote but no upvote for me either! Expand your answer with a valuable summary of the article to make it into a real answer!: meta.stackexchange.com/a/8259/172394 – Hindrance

I tried to include a summary of my link I hope now it is worth a good stackoverflow answer. – Undesigning

just a quick addition, checking the last update - argparse 2023 (github.com/python/cpython/blob/3.11/Lib/argparse.py). - docopt 2018 (github.com/docopt/docopt). - invoke 2023 (pypi.org/project/invoke/#history) I would stick to argparse, included default as part of all versions to be safe. – Borroff

Answer 5

At first I was as reluctant as @fmark to switch from optparse to argparse, because:

1. I thought the difference was not that huge.
2. Quite some VPS still provides Python 2.6 by default.

Then I saw this doc, argparse outperforms optparse, especially when talking about generating meaningful help message: http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html

And then I saw "argparse vs. optparse" by @Nicholas, saying we can have argparse available in python <2.7 (Yep, I didn't know that before.)

Now my two concerns are well addressed. I wrote this hoping it will help others with a similar mindset.

Arraignment