GeezerVison is showing github.com — Consider having int() support MINUS SIGN · Issue #144087 · python/cpython
Consider having int() support MINUS SIGN #144087DescriptionThe int() function supports all Nd unicode digit variants so that int('\N{digit one}') == int('\N{arabic-indic digit one}').
Likewise, the int() function supports all Zs space character variants to that int('\N{space}123') == int('\N{no-break space}123').
However, the function does not support negation variants so that int('\N{hyphen-minus}\N{digit one}') succeeds while int('\N{minus sign}\N{digit one}') fails.
I found this issue while parsing a Table of Jacobi Symbol Values. All of the −1 entries are a MINUS SIGN and DIGIT ONE. I would have expected all minus sign variants to be supported.
Linked PRs
Reacted by Martin Panter, Bartosz Sławecki, Łukasz Langa and Jason R. Coombs Activityjohnslavik commented on Jan 21, 2026 If we normalize MINUS SIGN to HYPHEN-MINUS in _PyUnicode_TransformDecimalAndSpaceToASCII, that will also affect float and complex. I think this is the correct and desired approach.
We can consider updating _pylong.str_to_int, but it is not used by us and maybe that one would need a more general rework (rather than just changing one specific thing to increase parity) according to this comment:
|
def str_to_int(s): |
|
"""Asymptotically fast version of decimal string to 'int' conversion.""" |
|
# FIXME: this doesn't support the full syntax that int() supports. |
We don't use this one internally. We instead sometimes use _pylong.int_from_string that has sign conversion already covered by _PyUnicode_TransformDecimalAndSpaceToASCII when called.
I believe _PyUnicode_TransformDecimalAndSpaceToASCII to be the right place to handle this. johnslavik commented on Jan 21, 2026 skirpichev commented on Jan 21, 2026
the function does not support negation variants so that int('\N{hyphen-minus}\N{digit one}') succeeds while int('\N{minus sign}\N{digit one}') fails.
Indeed, this looks odd. The \N{plus sign} is supported.
all minus sign variants
Could you be more precise here, do we need something else?
I imagine, that many dash-like characters might erroneously be used for minus sign. E.g.:
>>> s = '\u2011\N{digit one}'; print(s)
‑1
>>> -1 # find the difference? :-)
-1
>>> int(s)
Traceback (most recent call last):
File "<python-input-6>", line 1, in <module>
int(s)
~~~^^^
ValueError: invalid literal for int() with base 10: '‑1'johnslavik commented on Jan 21, 2026 @skirpichev yes, but MINUS SIGN is specifically supposed to be used as the mathematical minus. That's why it ended up on Wikipedia.
IMO, MINUS SIGN is the right additional case to support, and anything else that looks similar is okay to be unsupported. We could revisit any additional cases if someone asks for it, but my gut instinct is that it's very unlikely. Reacted by Sergey B Kirpichev, Łukasz Langa and Jason R. Coombs skirpichev commented on Jan 21, 2026
If we normalize MINUS SIGN to HYPHEN-MINUS in _PyUnicode_TransformDecimalAndSpaceToASCII, that will also affect float and complex.
That's ok, as they all support unicode digits.
But not forget about Decimal's, which don't use this helper. Reacted by Bartosz Sławecki johnslavik commented on Jan 21, 2026
But not forget about Decimal's, which don't use this helper.
Good note. For the decimal type, we'd update numeric_as_ascii.
Fractions don't support MINUS SIGN as well:
>>> fractions.Fraction("\N{MINUS SIGN}1")
Traceback (most recent call last):
...
ValueError: Invalid literal for Fraction: '−1'
>>> fractions.Fraction("-1")
Fraction(-1, 1)for these we'd update fractions._RATIONAL_FORMAT. skirpichev commented on Jan 21, 2026
Fractions don't support this as well
Yeah. You will need to change fractions module just like _pydecimal. Reacted by Bartosz Sławecki johnslavik commented on Jan 21, 2026 FWIW, wcstol doesn't seem to support this.
However, given prior discussions years ago, I think this is still a good idea, esp. for parsing documents that contain numbers with this sign.
To me, this is similar in nature to handling the final form of capital sigma Σ in str.lower(). johnslavik commented on Jan 21, 2026 johnslavik commented on Jan 21, 2026 rhettinger commented on Jan 21, 2026 ContributorAuthor More actions
all minus sign variants
Could you be more precise here, do we need something else?
MINUS SIGN and HYPHEN-MINUS are the only ones I know of. encukou commented on Mar 3, 2026 The non-ASCII decimal digits have some backing in Unicode -- there are official categories for decimal digits, and their values. [1]
But there's no such thing for signs like minus. We're essentially doing the job of the Unicode consortium -- deciding on character properties. Doing that correctly is hard. I don't know how to do it correctly, but I know we're all out of our depth here.
Adding a character after of seeing it used in a table is a bad precedent; it leaves us with unbounded scope for similar requests in the future. That's not a good thing to maintain.
Do you have some specific idea?
The default is to keep the status quo. Accepting only - and + is fine.
[1] I'd argue that we're not using them correctly though -- int('१২௩4') is just nonsense. That's water under the bridge, but let's not spill it further. randolf-scholz commented on Mar 3, 2026
But there's no such thing for signs like minus.
There are decompositions:
>>> import unicodedata
>>> unicodedata.name("\uff0d")
'FULLWIDTH HYPHEN-MINUS'
>>> unicodedata.decomposition("\uff0d")
'<wide> 002D'However, U+2212 (MINUS SIGN) does not decompose. encukou commented on Mar 9, 2026 Should we honour decompositions?
int('²') and float('3ₑ2') currently raise, though these strings decompose to 2 and 3e2. skirpichev commented on Mar 10, 2026
there are official categories for decimal digits, and their values.
Sign characters is a too narrow area to deserve a separate category.
But there's no such thing for signs like minus.
IMO, character name (\N{minus sign}) and its category (Math symbol, mathematical operators) speaks for itself.
int('²') and float('3ₑ2') currently raise
I think it's correct. '²' is a superscript character, 'ₑ' - subscript. This is for powers, array indexes and so on. johnslavik commented on Mar 12, 2026 This feature was requested and accepted long ago. I think we can add support for more signs over time as needed. johnslavik commented on Apr 1, 2026
The int() function supports all Nd unicode digit variants (...).
Likewise, the int() function supports all Zs space character variants (...).
However, the function does not support negation variants (...)
@rhettinger, is parity with existing support for Unicode characters the only rationale for this proposal? Does it aim to fully solve a bigger, well-defined problem, or is it a mere convenience? cc @ambv
I'm considering whether keeping the status quo with an easy str.replace always at hand isn't more desirable. Are there any cases you have (or had) in mind where having Unicode minus sign support in the int constructor (and, with the current state of things, in float and complex constructors as well) would be an undeniable win?
Personally, parity was the only argument that initially bought me, but now I'm having second thoughts. I'm looking at https://peps.python.org/pep-0672/#confusable-digits and I'm thinking: oh no, this is some shady business. johnslavik commented on Apr 1, 2026
I'd zero in on MINUS SIGN, in parity with the ASCII PLUS SIGN that is already supported.
I've used this argument but it doesn't work if we look at it within Python. All Python operators are ASCII, and that means the ASCII hyphen minus is more relevant than the Unicode minus sign when collating with ASCII plus sign. skirpichev commented on Apr 1, 2026
I'm looking at https://peps.python.org/pep-0672/#confusable-digits and I'm thinking: oh no, this is some shady business.
What you find confusing in the minus sign?
All Python operators are ASCII
Current proposal doesn't touch operators. It's not about of the language syntax, but about string parsing. To make it useful, we must accept more permissive syntaxes. Convenience is an argument here. If unicode character is used on practice as an alternative to ASCII minus - why reject it?
Supporting arbitrary unicode digits was rather an unfortunate precedent, as it now allows to mix them in a meaningless way, e.g. eastern and western arabic digits in one number. But it's already there... encukou commented on Apr 2, 2026
I'm considering whether keeping the status quo with an easy str.replace always at hand more desirable.
IMO, for the Unicode minus sign, it is.
As a first step toward adding more other characters, this is an issue with extremely large potential scope. Before opening the can of worms, we should have an idea of how far down the rabbit hole we're willing to go, and which dead ends we avoid.
“ASCII-only” is a good line to draw. Reacted by Bartosz Sławecki skirpichev commented on Jul 21, 2026
“ASCII-only” is a good line to draw.
The problem is that line was already crossed. E.g. from the issue description:
The int() function supports all Nd unicode digit variants so that int('\N{digit one}') == int('\N{arabic-indic digit one}').
I think that a strong point in favor is that it mirrors the unicode plus sign (\N{plus sign}), which is already supported. That was already noticed in previous discussions: https://mail.python.org/pipermail/python-ideas/2013-June/021273.html
But that is from purity arguments. Strongest one is from practice:
I found this issue while parsing a Table of Jacobi Symbol Values. All of the −1 entries are a MINUS SIGN and DIGIT ONE.
johnslavik commented on Jul 21, 2026
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|