Docs: getopt is deprecated in Python 3.13

[hugovk]

Let's list it alongside optparse on https://docs.python.org/3.13/library/superseded.html.

Re:

• https://docs.python.org/3.13/whatsnew/3.13.html#deprecated
• Document PEP 387 Soft Deprecation #106535

---

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

[vstinner]

Docs: getopt is deprecated in Python 3.13 #109438

It's only soft deprecated! That's very different from being deprecated ;-) Some people already got upset that I soft deprecated getopt! https://docs.python.org/dev/glossary.html#term-soft-deprecated

[ericvsmith]

Personally I think it's a mistake to even soft deprecate getopt and optparse, when argparse has some bugs we're never going to fix, such as issue #53580. That leaves us without an argument parser that can handle "--foo --bar --bar", if --foo is an option that takes an argument and --bar is another option.

[vstinner]

I suggest fixing argparse in this case.

[ericvsmith]

As the long (13 year!) discussion on the noted ticket points out, this isn't possible without rewriting argparse. And it's also impossible without breaking existing code or adding a separate parsing algorithm. So I don't think that's a viable course of action. Which leaves us without a usable, un-deprecated option parser. If that's our position, I think we should also soft deprecate argparse. I'd be okay with that.

[vstinner]

As the long (13 year!) discussion on the noted ticket points out, this isn't possible without rewriting argparse.

In this case, yep, it should be rewritten. If the issue exists for 13 years, maybe it's not really a big deal, otherwise a solution would pop up :-) Or people just moved to other modules which already handle this case.

And it's also impossible without breaking existing code or adding a separate parsing algorithm.

The new behavior can be an opt-in option. Or if you prefer, the old behavior can be an opt-in option.

Apparently, it's not possible to have a single default which fits all use cases, so having options make sure. For example, I like using parser.parse_known_args() explicitly for the behavior that I prefer :-)

Which leaves us without a usable, un-deprecated option parser.

getopt and optparse are only soft deprecated. It's not a regular "hard" deprecation.

If that's our position, I think we should also soft deprecate argparse. I'd be okay with that.

If you are concerned by the state of "parse command line arguments" modules in the stdlib, I suggest you opening a discussion on https://discuss.python.org/ to reach a larger audience, rather than commenting this closed PR.

If there are better alternatives to argparse, the doc can link to them. We already do that for other modules:

See also: The Requests package is recommended for a higher-level HTTP client interface.

https://docs.python.org/dev/library/urllib.request.html#module-urllib.request

[ericvsmith]

I'm only commenting here because I think the soft deprecation of getopt was a mistake without looking at the larger picture.

I'll open a discussion on d.p.o when I have some time. Or maybe bring it up at the core sprint for starters.