PR review: Fix argparse namespace overridden

Core Development
1

Hi, I have a PR open for nearly one year.

It is to fix an issue: gh-89398. Can anyone kindly review and possibly merge this? There is already a basic review by Jelle Zijlstra

2

I have a feeling that your PR is not getting merged because argparse is poorly specified and for every unexpected behavior that you would like to fix there seems to be a user who actually relies on the current behavior and whose code will be broken by the fix. IIRC in the not so distant past weā€™ve had to retract some argparse fixes for this reason, so everybody is wary of making changes.

3 Likes
3

I agree thatā€™s the problem, especially with subparsers. Personally, after looking at Issue 9334: argparse does not accept options taking arguments beginning with dash (regression from optparse) - Python tracker for 10 years, I think argparseā€™s design is just broken. I no longer use it, and have stopped looking at bug reports for it.

It would be nice to deprecate it and move it to PyPI where it could evolve, but Iā€™m not sure who would take ownership. So it will probably sit in the stdlib forever, not getting much attention.

5 Likes
4

We could still deprecate it even if we donā€™t have any plans to remove it.

Iā€™m hoping to bring up stdlib guidelines/maintenance/whatever at the language summit in April.

5

I think argparseā€™s design is just broken. I no longer use it, and have stopped looking at bug reports for it.

Ouch. The main thing I work on is still using optparse, mainly because argparse and the (officially deprecated) optparse are broken in disjoint enough ways that the conversion is more painful than anyoneā€™s been willing to sign up for. Iā€™ve kind of been kicking myself for not working up that enthusiasm, but nowā€¦

Is it a given that the stdlib must have a cli-parsing module? There are three at the moment, and a multitude of non-stdlib projects that are sure they solve the problem the One True Way. Different choices are not necessarily a problem, but this feels more confusing than it needs to be.

This does sort of feel like a topic that could be brought up at a language summit - is there anything thatā€™s worthwhile to discuss in the meantime?

6

Thatā€™s one of the questions to ask about the purpose and future of the stdlib as thereā€™s no agreed-upon answer to that as we have no guidelines around the stdlib.

7

We will never remove any of the CLI parsing libraries in the stdlib because they are all being actively used.

3 Likes
8

So I can go back to my comfy getopt module? :wink:

9

For us UNIX-y types, thatā€™s fine :slight_smile:

Disclaimer: this is going to sound snarky, actually meant to be silly:

There should be one-- and preferably only one --obvious way to do it.

ā€¦ except for command-line parsing, where there are three included ways to do it, all suboptimal. But hey, there are lots of other ways on PyPI, or you could roll your own, so nothing confusing there.

1 Like
10

Exactly, this PR is to fix the same issue with a more careful implementation.

I totally agree with the concerns and accept the decision to not touch this module. Thanks.

1 Like
11

I just canā€™t review it.