Commit 7c1de49
Zo Bot
reject unicode numerics that int() cannot parse in parse_format_options
parse_format_options decided whether to coerce a value to int by calling
str.isnumeric(). isnumeric returns True for several character classes
that int() cannot parse — Unicode vulgar fractions like ½, superscript
digits like ², and other locale-specific digit systems. The mismatch
was hidden: isnumeric() accepted the value, then int() raised an
unhandled ValueError that propagated out of the argparse type and
crashed the whole --format-options parse step. The Arabic-Indic
digits (0-9 U+0660..U+0669) actually do round-trip through int() on
some Python builds but produce int values whose equality with the
type of the default below depended on the Python build's codec tables,
so even values that "worked" could silently mismatch the default_type
check.
Replace the isnumeric() branch with a direct try/except int(value)
fallback so anything isnumeric() let through but int() cannot parse
now falls into the existing type-mismatch branch and raises a clear
ArgumentTypeError naming the offending token. Added three parametrized
cases to test_parse_format_options_errors covering ½, ², and ٣; the
existing 13 format_options tests continue to pass.1 parent 5b604c3 commit 7c1de49
2 files changed
Lines changed: 16 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
225 | 225 | | |
226 | 226 | | |
227 | 227 | | |
228 | | - | |
| 228 | + | |
| 229 | + | |
| 230 | + | |
| 231 | + | |
| 232 | + | |
| 233 | + | |
| 234 | + | |
| 235 | + | |
| 236 | + | |
| 237 | + | |
| 238 | + | |
| 239 | + | |
229 | 240 | | |
230 | | - | |
| 241 | + | |
231 | 242 | | |
232 | 243 | | |
233 | 244 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
439 | 439 | | |
440 | 440 | | |
441 | 441 | | |
| 442 | + | |
| 443 | + | |
| 444 | + | |
442 | 445 | | |
443 | 446 | | |
444 | 447 | | |
| |||
0 commit comments