Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Incorporate improvements from Serhiy's PR
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
  • Loading branch information
ncoghlan and serhiy-storchaka committed Oct 31, 2024
commit 55b72155bc4d623e37b41a1b3397c3618f588dc9
8 changes: 6 additions & 2 deletions Doc/library/argparse.rst
Original file line number Diff line number Diff line change
Expand Up @@ -14,10 +14,14 @@
.. note::

While :mod:`argparse` is the recommended standard library module for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not recommend it for now. You can use it on your own risk. optparse may need more work, but it works as expected. I would recommend it for beginners, which cannot distinguish their own errors from peculiarities of the library.

Copy link
Contributor Author

@ncoghlan ncoghlan Oct 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this PR, I'd like to stick with the status quo as far as recommendations go (that is, only taking the step back from "argparse is the only non-deprecated argument processing option in the standard library").

Taking the extra step to saying "argparse is not recommended over optparse anymore, even for end user applications" would then be a separate follow up question.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Keep the argparse recommendation. We're not going to dis-recommend the most widely used Python argument parsing library in the world (that causes churn and angst from users). Nor are we going to be adding yet another one to the stdlib in the future. argparse supports most users quite well, "warts" and all, with plenty of popular third party options for yet other behaviors beyond our stdlib options.

*implementing* command line applications, authors of third party
*implementing* basic command line applications, authors of third party
command line argument processing libraries may find that the
lower level :mod:`optparse` module serves as a better foundation for
that use case.
that use case. ``optparse`` (or one of the third party libraries
based on it) may also be worth considering for applications where
stricter adherence to common Unix and Linux command line interface
conventions around the handling of option parameter values that start
with ``-`` is desired.

--------------

Expand Down
27 changes: 23 additions & 4 deletions Doc/library/getopt.rst
Original file line number Diff line number Diff line change
Expand Up @@ -139,13 +139,25 @@ In a script, typical usage is something like this::
output = a
else:
assert False, "unhandled option"
# ...
process(args, output=output, verbose=verbose)

if __name__ == "__main__":
main()

Note that an equivalent command line interface could be produced with less code
and more informative help and error messages by using the :mod:`argparse` module::
and more informative help and error messages by using the :mod:`optparse` module::

import optparse

if __name__ == '__main__':
parser = optparse.OptionParser()
parser.add_option('-o', '--output')
parser.add_option('-v', dest='verbose', action='store_true')
opts, args = parser.parse_args()
process(args, output=opts.output, verbose=opts.verbose)

An equivalent command line interface for this simple case can also be produced
by using the :mod:`argparse` module::

import argparse

Expand All @@ -157,8 +169,15 @@ and more informative help and error messages by using the :mod:`argparse` module
# ... do something with args.output ...
# ... do something with args.verbose ..

In more complex cases (such as options which accept values), the behaviour
of the ``argparse`` version may diverge from that of the ``getopt`` and
``optparse`` versions due to the way ``argparse`` handles parameter
values that start with ``-``.

.. seealso::

Module :mod:`argparse`
Alternative command line option and argument parsing library.
Module :mod:`optparse`
More object-oriented command line option parsing.

Module :mod:`argparse`
More opinionated command line option and argument parsing library.
9 changes: 5 additions & 4 deletions Doc/library/optparse.rst
Original file line number Diff line number Diff line change
Expand Up @@ -46,10 +46,11 @@
--------------

:mod:`optparse` is a more convenient, flexible, and powerful library for parsing
command-line options than the old :mod:`getopt` module. :mod:`optparse` uses a
more declarative style of command-line parsing: you create an instance of
:class:`OptionParser`, populate it with options, and parse the command
line. :mod:`optparse` allows users to specify options in the conventional
command-line options than the minimalist :mod:`getopt` module.
:mod:`optparse` uses a more declarative style of command-line parsing:
you create an instance of :class:`OptionParser`,
populate it with options, and parse the command line.
:mod:`optparse` allows users to specify options in the conventional
GNU/POSIX syntax, and additionally generates usage and help messages for you.

Here's an example of using :mod:`optparse` in a simple script::
Expand Down
Loading