Skip to content

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

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.

Sign up for GitHub

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

Merged
ncoghlan merged 21 commits into from
Dec 23, 2024
Merged

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

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
21 commits
Select commit Hold shift + click to select a range
a560986
Remove getopt and optparse deprecation notices
ncoghlan Oct 31, 2024
0a568f1
Wording tweaks
ncoghlan Oct 31, 2024
55b7215
Incorporate improvements from Serhiy's PR
ncoghlan Oct 31, 2024
0971780
Grammar fix
ncoghlan Oct 31, 2024
09b0237
Fix issue number reference
ncoghlan Oct 31, 2024
4cdebde
Another wording tweak
ncoghlan Oct 31, 2024
693a979
Update heading and description for new chapter
ncoghlan Oct 31, 2024
50d1ee4
fileinput belongs in the new chapter
ncoghlan Oct 31, 2024
4e50c74
Move getopt back to the superseded section
ncoghlan Oct 31, 2024
0db2c88
Reword superseded chapter intro
ncoghlan Oct 31, 2024
e474e77
Simplify wording
ncoghlan Oct 31, 2024
43234de
Merge remote-tracking branch 'origin/main' into reverse-getopt-optpar…
ncoghlan Nov 2, 2024
93d7161
Updates based on Serhiy's feedback
ncoghlan Nov 2, 2024
bb91b52
Also reword What's New entry
ncoghlan Nov 2, 2024
7cc72ad
Consistent getopt markup
ncoghlan Nov 2, 2024
7f51456
Merge remote-tracking branch 'origin/main' into reverse-getopt-optpar…
ncoghlan Dec 8, 2024
5d86774
Updates based on review feedback
ncoghlan Dec 8, 2024
c2ae293
Syntax fix
ncoghlan Dec 8, 2024
5e2fcd9
Fix excess indentation in examples
ncoghlan Dec 17, 2024
457ee88
Phrasing tweak
ncoghlan Dec 17, 2024
f67d20c
Merge branch 'main' into reverse-getopt-optparse-deprecations
ncoghlan Dec 17, 2024
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
Wording tweaks
  • Loading branch information
@ncoghlan
ncoghlan committed Oct 31, 2024
commit 0a568f145f44148873ce7bf3a57b24cad3efbb02
2 changes: 1 addition & 1 deletion Doc/howto/argparse.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Note also that :mod:`argparse` is based on :mod:`optparse`,
and therefore very similar in terms of usage.

Expand Down
2 changes: 1 addition & 1 deletion Doc/library/argparse.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@
While :mod:`argparse` is the recommended standard library module for
Copy link
Member

@serhiy-storchaka serhiy-storchaka Oct 31, 2024

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 •
edited
Loading

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

@gpshead gpshead Nov 8, 2024

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
command line argument processing libraries may find that the
simpler :mod:`optparse` module serves as a better foundation for
lower level :mod:`optparse` module serves as a better foundation for
that use case.

--------------
Expand Down
4 changes: 2 additions & 2 deletions Doc/whatsnew/3.13.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1655,8 +1655,8 @@ optparse
While :mod:`argparse` remains preferred for new projects that
aren't using a third party command line argument processing
library, there are aspects of the way ``argparse`` works that
means ``optparse`` may provide a better foundation for *writing*
argument processing libraries.
means the lower level ``optparse`` module may provide a better
foundation for *writing* argument processing libraries.
(Contributed by Alyssa Coghlan in :gh:`126225`.)


Expand Down
2 changes: 1 addition & 1 deletion Misc/NEWS.d/next/Library/2024-10-31-14-31-36.gh-issue-126225.vTxGXm.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,4 +3,4 @@ There are legitimate reasons to use one of these modules in preference to
:mod:`argparse`, and none of these modules are at risk of being removed
from the standard library. Of the three, ``argparse`` remains the
recommended default choice, *unless* one of the concerns noted at the top of
the module documentation applies.
the ``optparse`` module documentation applies.