On Sun, 27 Dec 2020 at 19:31, Chris Angelico <ros...@gmail.com> wrote:
> On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno <jsbu...@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-le...@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/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/X3DYXKVBABN7IUCQQM7TWL4O3OUPW7U3/ Code of Conduct: http://python.org/psf/codeofconduct/
