New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent type-deduction of decimal floating-point #47610
Comments
When constructing a floating-point value, literals are apparently Example:
>>> x = 02120246124e0
>>> x = 02120246124.0
>>> x = 021202461241e0
ValueError: invalid literal for long() with base 8: '021202461241e0'
>>> x = 021202461241.0
ValueError: invalid literal for long() with base 8: '021202461241.0' I am using Python 2.5.1 from openSuSE 10.3. |
I get the same behavior in the trunk (on OS X 10.5), though it's not a I agree that this is undesirable behaviour, and I think it should be >>> 020000000000.0
ValueError: invalid literal for long() with base 8: '020000000000.0'
>>> 019999999999.0
19999999999.0 |
Some additional information: My original report was with an x86 system. Now, I'm sitting in front of an x86_64 system running Python 2.4.4 (from |
Not even with really large values? What happens on 64-bit with
? (that's 20 zeros between the 8 and the decimal point...) |
> >>> x = 0800000000000000000000.0
Urk. That should be:
The problem is in the parsenumber function in Python/ast.c. The Now I just have to figure out where to add tests for this. Maybe there |
Found it. Tests in test_compile.py. Fixed in the trunk in r65005. This should probably also be backported to Thanks for the report, Richard! |
Fixed in the 2.5 branch, r65007. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: