-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
base: main
Are you sure you want to change the base?
gh-126180: Remove getopt and optparse deprecation notices #126227
Conversation
Co-authored-by: Serhiy Storchaka <[email protected]>
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. |
There was a problem hiding this comment.
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)
There was a problem hiding this 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. |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
conventions around the handling of option parameter values that start | ||
with ``-`` is desired. |
There was a problem hiding this comment.
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
).
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
argparse.rst | ||
optparse.rst |
There was a problem hiding this comment.
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:: |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
# ... do something with args.output ... | ||
# ... do something with args.verbose .. |
There was a problem hiding this comment.
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)
``optparse`` versions due to the way ``argparse`` handles parameter | ||
values that start with ``-``. |
There was a problem hiding this comment.
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.
@serhiy-storchaka I think several of your suggestions are good improvements. I should have time to incorporate them tomorrow (Nov 1 AEST) |
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/