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
Argparse does not identify negative numbers with underscores as a numerical value #123945
I am not actually sure that this issue should be classified as a bug. There was no promise that argparse supports all numbers supported by Python (and it does not support numbers in scientific notations like -1e3, or complex numbers like -1j, or different decimal separators like -12,3). Underscores are supported for readability, but humans do not use underscores when they specify negative numbers for argparse (because this does not work). Generated data also usually do not contain underscores in numbers. So this change can help future users of argparse, but does not fix existing issue (for which users need to use workarouds).
I wonder whether we should make the check even more lenient, for example -\.?\d. This would help the user to support all numbers mentioned above (-1e3, -1j, -12,3 and also hexadecimals -0xabc, etc) if they use custom converter. Currently the only workaround is to override private member _negative_number_matcher in the parser constructor and the add_mutually_exclusive_group() method.
At some point I needed something to accept floats using all kind of notations. So what I did is replace the action by some ast.literal_eval call. Do you think a LiteralEval action would make sense actually? in addition, we could have a type for that action which would then check that the evaluation's result is of correct type (we could also restrict ast.literal_eval so that only truly constant expressions are accepted, and reject arithmetic)
@serhiy-storchaka Right now, we actually do accept numbers like positive versions of scientific notation and complex numbers...but not negative (we didn't before either). I will open a PR to get us to parity.
Activity
hugovk commentedon Sep 11, 2024
Small reproducer:
Reproducible on
main. Positive values will accept underscore, but not negative:savannahostrowski commentedon Sep 11, 2024
I'll take a look at this!
coppinri commentedon Sep 12, 2024
Thanks for picking this up.
Just a quick note on the proposed regex:
The proposed regex may accept numbers like:
-_.001that may not be inline with the python parser, but I haven't check with theThere is also no provision for underscores in the fractional part of the number.
GH-123945: Update regex for parsing negative numbers that contain und…
pythonGH-123945: Update regex for parsing negative numbers that conta…
pythonGH-123945: Update regex for parsing negative numbers that conta…
serhiy-storchaka commentedon Sep 23, 2024
The last change introduced a regression:
-.5no longer accepted as a negative number.serhiy-storchaka commentedon Sep 23, 2024
I am not actually sure that this issue should be classified as a bug. There was no promise that argparse supports all numbers supported by Python (and it does not support numbers in scientific notations like
-1e3, or complex numbers like-1j, or different decimal separators like-12,3). Underscores are supported for readability, but humans do not use underscores when they specify negative numbers for argparse (because this does not work). Generated data also usually do not contain underscores in numbers. So this change can help future users of argparse, but does not fix existing issue (for which users need to use workarouds).hauntsaninja commentedon Sep 23, 2024
Yeah, I agree, let me close the backports.
hauntsaninja commentedon Sep 23, 2024
Okay great, looks like Savannah fixed the regression in #124321 , so I think we can call this one closed 🎉
gpshead commentedon Sep 23, 2024
fwiw that makes sense, supporting parsing these is more "feature-ish". thanks for closing the backport PRs.
serhiy-storchaka commentedon Sep 23, 2024
I wonder whether we should make the check even more lenient, for example
-\.?\d. This would help the user to support all numbers mentioned above (-1e3,-1j,-12,3and also hexadecimals-0xabc, etc) if they use custom converter. Currently the only workaround is to override private member_negative_number_matcherin the parser constructor and theadd_mutually_exclusive_group()method.picnixz commentedon Sep 27, 2024
At some point I needed something to accept floats using all kind of notations. So what I did is replace the action by some
ast.literal_evalcall. Do you think aLiteralEvalaction would make sense actually? in addition, we could have a type for that action which would then check that the evaluation's result is of correct type (we could also restrictast.literal_evalso that only truly constant expressions are accepted, and reject arithmetic)savannahostrowski commentedon Sep 27, 2024
@serhiy-storchaka Right now, we actually do accept numbers like positive versions of scientific notation and complex numbers...but not negative (we didn't before either). I will open a PR to get us to parity.