On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno <jsbueno@python.org.br> 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.
Sorry, I thought my message conveyed that I know "float" exists, and
try/except is the current usable pattern (it is in the original posting anyway)
I tried to make clear this should be in addition to that -
But yes, I failed to mention in my message that I think such a function
would mostly benefit beginners learning around with "input" and "print" -
it is painful to suddenly have to tour the students on several other concepts just
to get a correct user-inputed number. (OTOH, yes, for code on this level,
one normally won't be concerned if the program user will be typing "1.02e2" on
the `input` prompt).
The point is exactly that parsing a number correctly, and moreover respecting
these options, is subject to error and the stdlib could benefit from
a construct that would not require a try/except block for everything.
(As you can see, I contemplate that raising may be a desired option for
a flexible function, and there is an option for that in my example signature) .
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/F5TGEV5V4ZKAPSD5AI62EJ6YZRKQQPFQ/
Code of Conduct: http://python.org/psf/codeofconduct/