On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno email@example.com wrote:
I agree - the three builtin methods are almost the same (not sure if there is any difference at all),
Yes - they all check if the string matches a particular set of characters.
while there is no trivial way to check for a valid float, or otherwise a chosen representation of a decimal number without resorting to a try-except statement, or complicated verification schemes that have to deal with a lot of corner cases.
If you want to know whether the float() call will throw, the best way to check is to call float() and see if it throws.
For validity one has to check if there are only digits - and decimal points - and the "-" unary sign. What if there is more of a "." in the string? what if the "-" is not the first character? And besides validity checking, there are also validity choices: What if an unary "+" is present? Whitespace ok? "_" as digit separator ok? scientific exponential notation accepted? What about Inf and Nan literals? What about taking into account the locale setting?
But maybe, instead of yet another str method, a "parsefloat" function that could get arguments and sensitive defaults for some choices - it could live in "math" or "numbers".
How about a built-in called "float", which either returns the floating-point value represented by the string, or signals an invalid string with an exception?
I think it would be preferable than, say, adding a lot of options to the `float` constructor. These are the options I can think of the top of my mind:
YAGNI. If you want to allow specific subsets of valid options, it's not that hard to do your own validation.
The return value would consitss of a boolean, where True would indicate success, and then the number. Or it could return a single float, returning a NaN in case of parsing error.
Or it could raise in the case of parsing error. That's the Pythonic way.