This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients mark.dickinson, rhettinger, serhiy.storchaka, zd nex
Date 2020-03-14.10:41:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>

> I prefer what we have now.  The language is consistent [...]

Agreed. I don't see value in having two different sets of rules, one for numeric literals and one for explicit str-to-int conversions. And if we *were* to adopt a different set of rules for str-to-int conversions, what would those rules be? There are a lot of fairly arbitrary choices to make (whitespace before/after/between sign and digits, digit sets, leading zeros, characters permitted as signs, permissible digit separators).
The decision would be easier if there were a widespread standard that could help us choose a particular ruleset, but I'm not aware of any such standard.

Much cleaner and simpler to have the rules for str-to-int match those for numeric literal parsing. (And similarly for floats.)

[zd nex]
> I would suggest that it would be possible to strictly check strings [...]

As Serhiy pointed out, it already is possible, in a variety of ways. If you're arguing for something like `int("+123", strict=True)`, you'd need to say exactly what "strict=True" should mean, make a case that your particular choice is sufficiently standard and useful to others to make it worth adding to core Python, consider how it would interact with the "base" argument, and a whole lot more. If you want to take that forward, I think that's something you'd need to bring up on the python-ideas mailing list for further discussion. I'll close here.
Date User Action Args
2020-03-14 10:41:48mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, serhiy.storchaka, zd nex
2020-03-14 10:41:48mark.dickinsonsetmessageid: <>
2020-03-14 10:41:48mark.dickinsonlinkissue39956 messages
2020-03-14 10:41:47mark.dickinsoncreate