You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support parsing negative scientific notation and complex numbers in argparse #124693
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.
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?
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.
Activity
serhiy-storchaka commentedon Oct 1, 2024
argparseis weird.-x -yis considered an error if-xis 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 commentedon Oct 2, 2024
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 commentedon Oct 2, 2024
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
xargsorheadwhich support number-like options and allow option grouping (xargs -0n1andhead -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 commentedon Oct 3, 2024
Thanks for clarifying. Just wanted to make sure that there wasn't anything else to be done here that could help!
Merge branch 'main' into pythongh-124693
Merge branch 'main' into pythongh-124693
GH-124693: Support parsing negative scientific and complex numbers ar…
serhiy-storchaka commentedon Oct 9, 2024
Even if I did not solve any related issues, I think that this change is on safe side.