Uh oh!
There was an error while loading. Please reload this page.
gh-144087: Add support for unicode MINUS SIGN in int, float and complex - #144095
gh-144087: Add support for unicode MINUS SIGN in int, float and complex#144095johnslavik wants to merge 31 commits into
int, float and complex#144095Conversation
jaraco
commented
Jan 24, 2026
LGTM. Needs tests and blurb. Maybe consider making the assignment a constant instead of a comment, though I don't feel strongly about it. |
Yep! Work in progress. Thanks for chiming in :) |
skirpichev
commented
Jan 24, 2026
This also needs documentation. I would guess, it will take major part of the PR. |
picnixz
commented
Jan 28, 2026
How about only checking for the first non whitespace character? signs should not appear in the middle of a number unless they are in the e/E/p suffix I guess? |
skirpichev
commented
Jan 28, 2026
Hardly this optimizes something.
Yes. _PyUnicode_TransformDecimalAndSpaceToASCII() used for floats and complexes (which gives another case of "sign in the middle") too. |
Some tests are failing!
- `CAPIFloatTest.test_fromstring` doesn't test for minus signs - I can't find `complex` C API tests
I think that reads better
johnslavik
commented
Feb 21, 2026
This seems like something we could add to the "What's New" log. I'll do that. |
@picnixz, @skirpichev, I tagged you for reviews because I thought you may be interested now that it is ready :-) I'm particularly unsure about whether I missed or added unnecessary tests, and whether the documentation changes are good. |
Uh oh!
There was an error while loading. Please reload this page.
skirpichev
left a comment
There was a problem hiding this comment.
LGTM, with minor nitpicks.
Maybe you can do docs more compact. See suggestions as an example.
Alternatively, omit just "(ASCII plus sign)" clarifications. There shouldn't be much confusion. Visual difference for '-' and '−' is less apparent.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
skirpichev
left a comment
There was a problem hiding this comment.
Note also, that we have a separate parsing from string code in the fromhex() class method.
I don't see good reasons to reject new sign character here, if we are going to support in the float constructor.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| def test_float(self): | ||
| self.assertEqual(float(3.14), 3.14) | ||
| self.assertEqual(float(314), 314.0) | ||
| self.assertEqual(float(" 3.14 "), 3.14) |
There was a problem hiding this comment.
I think you can add here also tests for parsing floats in scientific notation, with exponent.
There was a problem hiding this comment.
Thanks, I'll address this on the weekend.
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
johnslavik
commented
Mar 24, 2026
Please do not merge this. I need to collect more feedback on the idea. |
This PR is stale because it has been open for 30 days with no activity. |
johnslavik
commented
Jul 20, 2026
I'm not sure it is worth it. Feel free to pick this up if you want! |
I don't see a different approach to solving this that is equally or more optimal in terms of trade-offs. If there's any alternative approach that I've missed, please let me know.