Why use argparse rather than optparse?
Rise to the top 3% as a developer or hire one of them at Toptal: https://topt.al/25cXVn
--------------------------------------------------
Music by Eric Matyas
https://www.soundimage.org
Track title: Techno Bleepage Open
--
Chapters
00:00 Why Use Argparse Rather Than Optparse?
00:25 Accepted Answer Score 360
01:03 Answer 2 Score 67
02:43 Answer 3 Score 41
02:59 Answer 4 Score 22
03:45 Answer 5 Score 6
04:20 Thank you
--
Full question
https://stackoverflow.com/questions/3217...
--
Content licensed under CC BY-SA
https://meta.stackexchange.com/help/lice...
--
Tags
#python #commandline #optparse #getopt #argparse
#avk47
ACCEPTED ANSWER
Score 360
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.
ANSWER 2
Score 67
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).
ANSWER 3
Score 41
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?
ANSWER 4
Score 6
At first I was as reluctant as @fmark to switch from optparse to argparse, because:
- I thought the difference was not that huge.
- 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.