`isdigit()` passed a superscript two that `int()` refused

Fun corner. int() doesn't care whether the digits come from the same script. int("1٣") is 13, one ASCII digit and one Arabic-Indic, and float("١.٥") gives 1.5. I expected mixing to be refused, the way some confusable checks refuse mixed scripts, but it's just per-character digit values added up.

So with isdecimal() the field takes numbers no single keyboard layout would type in one go. Paste 1٣ into it and see what the form echoes back.

That settled it for me, ASCII digits only. My first attempt was re.match(r"\d+$", s), and it had two problems I didn't see right away. \d in a str pattern matches every Unicode decimal digit, so ٣ still got in. And $ also matches just before a trailing newline, so "7\n" passed too. Here is what the field uses now.

import re

def parse_quantity(s: str) -> int | None:
    if re.fullmatch(r"[0-9]+", s):
        return int(s)
    return None

fullmatch with an explicit class answers one question, ASCII digits from the first character to the last. Spaces, signs and underscores get refused as well, even though int() itself would take " 7 " and "1_000".

Agree on fullmatch, the $ newline thing catches people constantly. Less sure about refusing full-width digits. Someone typing with a Japanese input method left in full-width mode produces ３ without noticing, and to them the error reads like the form rejecting the number 3. A ten-entry table handles that one case without opening the door to everything isdecimal() allows.

FULLWIDTH = str.maketrans("０１２３４５６７８９", "0123456789")
parse_quantity(s.translate(FULLWIDTH))

Superscripts and other scripts still get refused. Whether full-width deserves the exception is a judgment call, and I don't feel strongly enough to push it past this reply.

Real case, and the table is small. Still leaving it out for now, since the field sits next to plus and minus buttons and the error text says "use the digits 0 to 9".