On Sun, 27 Dec 2020 at 19:31, Chris Angelico <rosuav@gmail.com> wrote:
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) .  

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/