Closed SethMMorton closed 1 year ago
I have cleaned/moved up a conversation intended for #37.
Below is a comment by @argenisleon originally from #37 that instigated this issue being created (original comment deleted).
Just this morning I had this problem. From the readme:
# Check that a string can be converted to a float
isfloat('56')
True
# Check if a given number is a float
....
isfloat(56)
False
The same function seems to check if a string can be converted to a float but at the same time an int is a float. I think the question it should answer is this string or number a float?
In both cases I think the answer should be False
.
My point here is that as a user I am not sure what fastnumbers is trying to answer.
It is difficult for me as a new user to digest all the possible combinations of params of the current API and how it should work. I think we can map what the output should be in something like a minpmap https://miro.com/ and then go back to C and implement it.
What do you think?
And here was my comment originally from #37 to the direct above (original comment deleted).
Yeah, this isn't clear.
Basically, for string input I had implemented it to return True
if fast_float
would have returned a float
or not. But for numeric input I basically was checking the type. So it really behaves differently depending on the type.
Not cool.
This will probably require a backwards-incompatible change.
Describe the feature or enhancement The proposal is to change how
isfloat
interprets strings. Currently, it has the following behavior:The proposal is to change the behavior to the following:
Provide a concrete example of how the feature or enhancement will improve
fastnumbers
isfloat
is inconsistent. For strings that look like integers, it returnsTrue
, but for numeric types it is strict. In fact,isfloat
behaves identically toisreal
for string input. Users wanting to detect if string input is actually afloat
an not anint
cannot in a single call.The rational behind this was that for string input,
isfloat
would returnTrue
iffast_float
would successfully convert to afloat
. The intention was to introduce symmetry between the functions, but unfortunately this was not achieved because of how the function behaves with numeric input.Really, the current behavior of
isfloat
is acting likeisreal
.A successful introduction will have a deprecation schedule, so that users are not completely caught off-guard. At the very least, this needs to be advertised at the top of the README for a while.
NOTE: This was brought up as part of #37 by @argenisleon.