Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-126180: Remove getopt and optparse deprecation notices #126227

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

ncoghlan
Copy link
Contributor

@ncoghlan ncoghlan commented Oct 31, 2024

getopt and optparse are in no way at risk of being removed,
as they have genuinely valid use cases. Those use cases
(mimicing the C getopt API, implementing third party
command line argument processing libraries) are just
far less common than the ones that argparse addresses.

Relevant issue is #126180.


📚 Documentation preview 📚: https://cpython-previews--126227.org.readthedocs.build/

@ncoghlan ncoghlan changed the title gh-126225: Remove getopt and optparse deprecation notices gh-126180: Remove getopt and optparse deprecation notices Oct 31, 2024
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.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Replacing old with minimalist is the only actual wording change here (the rest is just reflowing text)

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

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

You are focused on one particular peculiarity in argparse, but there are many others. The difference is fundamental in the way how optional and positional arguments are parsed.

@@ -15,7 +15,7 @@ recommended command-line parsing module in the Python standard library.

There are two other modules that fulfill the same task, namely
:mod:`getopt` (an equivalent for ``getopt()`` from the C
language) and the deprecated :mod:`optparse`.
language) and the lower level :mod:`optparse` module.
Copy link
Member

Choose a reason for hiding this comment

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

This may create an impression that optparse is lower level than getopt.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll reorder it to make it clear the "lower level" comparison is relative to argparse

Comment on lines +23 to +24
conventions around the handling of option parameter values that start
with ``-`` is desired.
Copy link
Member

Choose a reason for hiding this comment

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

Not only this. There are other peculiarities that make implementation of compatible interface with argparse impossible (unlike to getopt and optparse).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I had gotten the impression from the Discourse thread that this was the primary quirk, but I can reword these caveats to be less specific to that one issue.

@@ -11,6 +11,18 @@

**Source code:** :source:`Lib/argparse.py`

.. 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.

Comment on lines +15 to +16
argparse.rst
optparse.rst
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 place optparse above argparse.

The :mod:`getopt` module is :term:`soft deprecated` and will not be
developed further; development will continue with the :mod:`argparse`
module.

.. note::
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 convert the note in normal paragraph. Also, it should refer to optparse as an object-oriented and extensible alternative, not only to argparse (which is not an equivalent).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I ended up moving this page back to the "Superseded" section of the docs, as it really is a niche use case when anyone should be reaching for this. The use of the note syntax here reflects that "You almost certainly don't want this module" status.

I agree about referring readers to optparse in the note, though.

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
Copy link
Member

Choose a reason for hiding this comment

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

Even in this simple example this is not an exact equivalent. For example, -o -v and -o -- do not work, -o=foo works differently, you cannot interleave options and positional arguments. I said this is "a roughly equivalent".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think if we elaborate on the discrepancies here, it may help lay the foundation for weakening the current recommendation to use argparse in a future PR. I'll incorporate more of your notes here tomorrow.

Comment on lines 169 to 170
# ... do something with args.output ...
# ... do something with args.verbose ..
Copy link
Member

Choose a reason for hiding this comment

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

I added this to show the difference in the API between three modules

       parser.add_argument('rest', nargs='*')
       args = parser.parse_args()
       process(args.rest, output=args.output, verbose=args.verbose)

Comment on lines +174 to +175
``optparse`` versions due to the way ``argparse`` handles parameter
values that start with ``-``.
Copy link
Member

Choose a reason for hiding this comment

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

The difference is not only in this.

@ncoghlan
Copy link
Contributor Author

@serhiy-storchaka I think several of your suggestions are good improvements. I should have time to incorporate them tomorrow (Nov 1 AEST)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants