gh-126180: Remove getopt and optparse deprecation notices by ncoghlan · Pull Request #126227 · python/cpython (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation56 Commits21 Checks35 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
gh-126225: Remove getopt and optparse deprecation notices gh-126180: Remove getopt and optparse deprecation notices
Co-authored-by: Serhiy Storchaka storchaka@gmail.com
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.
| @@ -11,6 +11,18 @@ |
|---|
| **Source code:** :source:`Lib/argparse.py` |
| .. note:: |
| While :mod:`argparse` is the recommended standard library module for |
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.
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.
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.
@serhiy-storchaka I think several of your suggestions are good improvements. I should have time to incorporate them tomorrow (Nov 1 AEST)
@serhiy-storchaka I won't get back to this today, and this weekend isn't looking good either. Early next week will probably be the next update.
@serhiy-storchaka I ended up procrastinating on my assignment by working on this (amongst other things), so I've pushed some updates for you to take a look at when you're back at work.
| Whether these differing behaviors in the ``argparse`` version are |
| considered desirable or a problem will depend on the specific command line |
| application use case. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@serhiy-storchaka ^^^ is the main reason I don't think we should walk back the default argparse recommendation. Many (probably even most) Python devs would consider argparse to be in the right for these 3 examples, and getopt/optparse the ones doing something dubious (even if what they're doing is the common Unix convention).
The discrepancies are valid reasons for reverting the soft deprecation (optparse can genuinely be used to define command line behaviours that argparse doesn't support), but it will take less arguable examples than these ones to make the case that optparse should be preferred over argparse in general.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better to write about these peculiarities in the argparse module documentation. The getopt module documentation is not the place where users will search information about the argparse module.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed. I like that we're giving a list of differences in behavior, but I think it makes more sense to put this in a common section :ref:'d from all three of our command line parsing module docs. I don't expect anyone reading argparse (most likely) or optparse (likely) docs to find this in the getopt docs (presumed least likely to be read).
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've moved this to a new "Choosing an argument parsing library" section at the start of the optparse docs. getopt still has the example code, but refers to that new section to explain the differences.
Similar, I made the note at the start of the argparse docs shorter, and added a link to this new section.
I forgot I had marked this as draft when it was clear it was going to take me a while to get back to it. Belatedly switched it back to ready for review after the last round of updates (this is the full version of the patch - once I made time for it, I made enough time for that rather than pursuing the interim change discussed above).
The DO-NOT-MERGE label was a mutual one with #126186 until we decided which of the PRs to use as the basis for docs updates. With #126186 closed, that means this one can be handled via the regular PR review process.
@serhiy-storchaka Let me know if you want to take another look before I merge this, otherwise I'll merge it early next week (a Christmas present for happy optparse and getopt users!).
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
From my perspective this is ready to go in. I didn't immediately click merge as I wanted to let others speak up if they believe otherwise. Edited quoting of myself from Discord:
"""
It's not like there is any big official "plan" (re: getopt, optparse, vs argparse) - the point of this PR to me is to remove the loaded term "deprecated" on the old ones because we're never going to remove them. We just want to guide users to argparse by default and point at the others as also available for specific needs. Between sys.argv, these three modules, and everything on PyPI I'm sure we have 14 ways to do command line parsing that are all wrong from someones perspective anyways.
I wouldn't encourage outsiders to contribute new features to getopt or optparse myself. But if a core dev is willing to review them and guarantee backwards compatibility with tests, go for it.
""" - me
Feel free to merge when you're ready.
Done! Thanks for the reviews, folks.
Thanks @ncoghlan for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request
- 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 831b6de)
Co-authored-by: Alyssa Coghlan ncoghlan@gmail.com Co-authored-by: Serhiy Storchaka storchaka@gmail.com
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this pull request
- 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
Co-authored-by: Serhiy Storchaka storchaka@gmail.com
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this pull request
- 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
Co-authored-by: Serhiy Storchaka storchaka@gmail.com
aaronliu0130 added a commit to aaronliu0130/pylint that referenced this pull request
jacobtylerwalls pushed a commit to pylint-dev/pylint that referenced this pull request
github-actions bot pushed a commit to pylint-dev/pylint that referenced this pull request
aaronliu0130 added a commit to aaronliu0130/pylint that referenced this pull request
jacobtylerwalls pushed a commit to pylint-dev/pylint that referenced this pull request
Upstream undeprecated it in December (python/cpython#126227)
(cherry picked from commit 47579c8)
Co-authored-by: Aaron Liu aaronliu0130@gmail.com
Reviewers
Labels
Documentation in the Doc dir