Menu
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?
307
For a more gentle introduction to Python command-line parsing, have a look at the argparse tutorial. The argparse module makes it easy to write user-friendly command-line interfaces. The program defines what arguments it requires, and argparse will figure out how to parse those out of sys. argv .
Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module. optparse is a more convenient, flexible, and powerful library for parsing command-line options than the old getopt module.
Click actually implements its own parsing of arguments and does not use optparse or argparse following the optparse parsing behavior. The reason it's not based on argparse is that argparse does not allow proper nesting of commands by design and has some deficiencies when it comes to POSIX compliant argument handling.
You can use the argparse module to write a command-line interface that accepts a positional argument. Positional arguments (as opposed to optional arguments, which we'll explore in a subsequent section), are generally used to specify required inputs to your program.
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/):
+ and / More information is also in PEP 389, which is the vehicle by which argparse made it into the standard library.
70
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).
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
