gh-126180: Remove getopt and optparse deprecation notices #126227
Conversation
ncoghlan
changed the title
Co-authored-by: Serhiy Storchaka <[email protected]>
Doc/library/argparse.rst
Outdated
| @@ -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.
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.
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.
There was a problem hiding this comment.
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. |
Doc/library/getopt.rst
Outdated
|
|
||
| Whether these differing behaviors in the ``argparse`` version are | ||
| considered desirable or a problem will depend on the specific command line | ||
| application use case. |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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). |
|
@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!). |
|
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: """ 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. |
…onGH-126227) * 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 <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
|
GH-128191 is a backport of this pull request to the 3.13 branch. |
…onGH-126227) * 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 <[email protected]>
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.
Closes #126180.
📚 Documentation preview 📚: https://cpython-previews--126227.org.readthedocs.build/