Let int accept scientific notation strings

Ideas
63

Well… int() used to be very strict in python2. But it was changed in python 3 with pretty much no discussion about the ramifications of making it much less strict. So we DID use something very strict, because we used python 2! And then when we upgraded to python 3, the looser parsing was missed during testing and thus the problem.

To me it’s pretty clear that the “be liberal in what you accept” idea is now thoroughly debunked :stuck_out_tongue:

64

This is tangential to the thread but, out of curiosity, how did the invalid data 123_2_3 arise?

65

Surely the point of that comment is that with the code

def to_number(s):
    try:
        x = int(s)
    except ValueError:
        x = float(s)

to_number() will silently give different results depending on the Python version (i.e. depending on whether this proposal has been implemented or not). Having your data analysis results change simply as a result of a Python upgrade is a rather bad thing to happen, and one we would normally try hard to avoid. In this case, there’s no indication that the benefit of the change justifies such breakage.

And yes, I know it’s probably rare that the value will change. But rare isn’t the same as impossible. And given the range of uses Python is put to, can you be sure that an error like this won’t have serious consequenses? I can’t.

3 Likes
66

Then we return to my question:

What I’m confused about is @storchaka’s claim that this proposal would “break code”. Their snippet must be a fragment of a larger program with some purpose. What program is that? In what situation would it be a problem to proceed with an int, instead of the corresponding float, when an int or float is expected?

67

In a situation where an int and its “corresponding float” give different answers!

Here’s a very simple example:

>>> as_int = int(10**23)
>>> as_float = 1e23
>>> as_int % 3
1
>>> as_float % 3
2.0

Is it so hard to understand that making code which currently returns the value 2, suddenly start returning the value 3, on the same input and without any warning is bad?

If you don’t think that’s a problem, then our understanding of what’s an incompatible change is irreconcilably different.

Also, see PEP 387 for more details on the policy around making incompatible changes. In particular, the comment

In general, incompatibilities should have a large benefit to breakage ratio, and the incompatibility should be easy to resolve in affected code.

2 Likes
69

I think the answer here is pretty clearly “no” at this point, so unless you have something constructive to add beyond “that’s silly, give me a better example”, I’m going to close this. You’ve been going in circles all day now, after almost a month of silence.

5 Likes
70

I object to you characterising my attempt to explain the issue with this proposal as “silly”. Have you read PEP 387 as I suggested? Do you understand that the responsibility is on the proposers to demonstrate that the benefits outweigh the risks, and that dismissing potential risks without proper assessment won’t help your case?

I see no reason to spend any more of my time trying to help you understand how to make a convincing argument for this proposal.

1 Like
71

You haven’t pointed out any “risks” of returning a precise int instead of an imprecise float in a situation where both int and float are accepted.

1 Like