mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-08-31 14:07:50 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 9

[3.13] gh-126180: Remove getopt and optparse deprecation notices (GH-128191)

Browse source 
* Remove getopt and optparse deprecation notices
* Add new docs sections for command line app helper libraries
* Add guidance on choosing a CLI parsing library to the optparse docs
* Link to the new guidance from the argparse and getopt docs
* Reword intro in docs section for superseded stdlib modules
* Reframe the optparse->argparse guide as a migration guide
  rather than as an upgrade guide

---------
(cherry picked from commit 831b6de6d7)

Co-authored-by: Alyssa Coghlan <ncoghlan@gmail.com>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
This commit is contained in:
Miss Islington (bot) 2024-12-23 05:40:59 +01:00 • committed by GitHub
parent 09d15aa9a8
commit 6f3c2c8d04
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
12 changed files with 266 additions and 65 deletions
Download patch file Download diff file Expand all files Collapse all files

36
Doc/howto/argparse-optparse.rst
View file

@ -1,20 +1,14 @@
.. currentmodule:: argparse
.. _upgrading-optparse-code:
.. _migrating-optparse-code:
==========================
Upgrading optparse code
==========================
============================================
Migrating ``optparse`` code to ``argparse``
============================================
Originally, the :mod:`argparse` module had attempted to maintain compatibility
with :mod:`optparse`. However, :mod:`optparse` was difficult to extend
transparently, particularly with the changes required to support
``nargs=`` specifiers and better usage messages. When most everything in
:mod:`optparse` had either been copy-pasted over or monkey-patched, it no
longer seemed practical to try to maintain the backwards compatibility.
The :mod:`argparse` module improves on the :mod:`optparse`
module in a number of ways including:
The :mod:`argparse` module offers several higher level features not natively
provided by the :mod:`optparse` module, including:
* Handling positional arguments.
* Supporting subcommands.
@ -23,7 +17,23 @@ module in a number of ways including:
* Producing more informative usage messages.
* Providing a much simpler interface for custom ``type`` and ``action``.
A partial upgrade path from :mod:`optparse` to :mod:`argparse`:
Originally, the :mod:`argparse` module attempted to maintain compatibility
with :mod:`optparse`. However, the fundamental design differences between
supporting declarative command line option processing (while leaving positional
argument processing to application code), and supporting both named options
and positional arguments in the declarative interface mean that the
API has diverged from that of ``optparse`` over time.
As described in :ref:`choosing-an-argument-parser`, applications that are
currently using :mod:`optparse` and are happy with the way it works can
just continue to use ``optparse``.
Application developers that are considering migrating should also review
the list of intrinsic behavioural differences described in that section
before deciding whether or not migration is desirable.
For applications that do choose to migrate from :mod:`optparse` to :mod:`argparse`,
the following suggestions should be helpful:
* Replace all :meth:`optparse.OptionParser.add_option` calls with
:meth:`ArgumentParser.add_argument` calls.