Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support parsing negative scientific notation and complex numbers in argparse #124693

Closed
savannahostrowski opened this issue Sep 27, 2024 · 5 comments
Assignees
Labels
3.14 new features, bugs and security fixes stdlib Python modules in the Lib dir type-feature A feature request or enhancement

Comments

@savannahostrowski
Copy link
Member

savannahostrowski commented Sep 27, 2024

Bug report

Per #123945 (comment)

Linked PRs

@savannahostrowski savannahostrowski added type-bug An unexpected behavior, bug, or error stdlib Python modules in the Lib dir labels Sep 27, 2024
@savannahostrowski savannahostrowski self-assigned this Sep 27, 2024
@serhiy-storchaka serhiy-storchaka added type-feature A feature request or enhancement 3.14 new features, bugs and security fixes and removed type-bug An unexpected behavior, bug, or error labels Oct 1, 2024
@serhiy-storchaka
Copy link
Member

argparse is weird. -x -y is considered an error if -x is known option that requires argument. This is a part of the design -- they prefer to consider it more likely that the user did not specify an argument for the option than that the argument begins with a dash. This creates a lot of inconvenience (see for example #66623, #118551, and more was closed), so there is a heuristic to compensate for this for the most common cases. For example, consider number-like arguments positional if there are no number-like options defined. The heuristic works not in 100%, and changing it can introduce new false positive or false negative cases.

That is why any changes should be treated with caution. I prefer not to merge the changes right now, but to wait for a while in case new circumstances arise. After all, this is not a very important case.

In any case this is rather a new feature than a bug.

@savannahostrowski
Copy link
Member Author

That makes sense. I totally agree and understand the hesitancy. There are lots of inconsistencies like this lying around, and fixing any one of them could definitely have side effects.

That said, I would like to understand what we are looking for in waiting. More specifically, what would we need to see to feel comfortable merging this change? Do you have specific criteria in mind?

@serhiy-storchaka
Copy link
Member

I do not know. It takes time to think things over. Perhaps new thoughts will arise while working on other issues.

I thought about how it can affect cases such as xargs or head which support number-like options and allow option grouping (xargs -0n1 and head -5v). It doesn't seem to make things any worse.

Nothing wrong with your PR (as it looks to me now), and most likely it will be merged in a week or two.

@savannahostrowski
Copy link
Member Author

Thanks for clarifying. Just wanted to make sure that there wasn't anything else to be done here that could help!

savannahostrowski added a commit to savannahostrowski/cpython that referenced this issue Oct 8, 2024
serhiy-storchaka added a commit to savannahostrowski/cpython that referenced this issue Oct 9, 2024
serhiy-storchaka added a commit that referenced this issue Oct 9, 2024
…gparse (GH-124823)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
@github-project-automation github-project-automation bot moved this to Doc issues in Argparse issues Oct 9, 2024
@serhiy-storchaka
Copy link
Member

Even if I did not solve any related issues, I think that this change is on safe side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.14 new features, bugs and security fixes stdlib Python modules in the Lib dir type-feature A feature request or enhancement
Projects
Status: Doc issues
Development

No branches or pull requests

2 participants