Skip to content

GH-124321: Argparse negative number parsing does not capture -.5 #124322

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Sep 23, 2024
Merged

GH-124321: Argparse negative number parsing does not capture -.5 #124322

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bb13946
Add another test case for -.5
savannahostrowski Sep 22, 2024
91db794
Update Lib/argparse.py
savannahostrowski Sep 23, 2024
1c24113
Update Lib/test/test_argparse.py
savannahostrowski Sep 23, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Lib/argparse.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1360,7 +1360,7 @@ def __init__(self,
self._defaults = {}

# determines whether an "option" looks like a negative number
self._negative_number_matcher = _re.compile(r'^-\d[\d_]*(\.\d[\d_]*)?$')
self._negative_number_matcher = _re.compile(r'^-(\d+(_\d+)*(\.\d+(_\d+)*)?|\.\d+(_\d+)*)$')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pattern looks fine for capturing negatives without a leading digit, but it does have a (rather silly) breaking change: -12__3 was accepted by the old pattern but not the new.

I think support for runs of underscores was accidental, though (and undocumented), so it seems fine to remove it. Would be remiss not to point it out, though!

A

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my gut feeling: we don't need to care if this is pedantically accurate? regexes are not great parsers. if a value that fails the actual parser makes it through, it'll be an SyntaxError/ValueError upon int() conversion. do we capture the exception within argparse at a reasonable place such that the error is reported to the user in a friendly manner associated with the argument? (anyways, I'd leave that for a followup issue if not)


# whether or not there are any optionals that look like negative
# numbers -- uses a list so it can be shared and edited
Expand Down
1 change: 1 addition & 0 deletions Lib/test/test_argparse.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2111,6 +2111,7 @@ class TestNegativeNumber(ParserTestCase):
('--int -1_000_000 --float -1_000_000.0', NS(int=-1000000, float=-1000000.0)),
('--float -1_000.0', NS(int=None, float=-1000.0)),
('--float -1_000_000.0_0', NS(int=None, float=-1000000.0)),
('--float -.5', NS(int=None, float=-0.5)),
]

class TestInvalidAction(TestCase):
Expand Down
Loading