classification
Title: Inconsistent type-deduction of decimal floating-point
Type: behavior Stage:
Components: Interpreter Core Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: mark.dickinson, richyk
Priority: high Keywords:

Created on 2008-07-15 10:45 by richyk, last changed 2008-07-16 11:05 by mark.dickinson. This issue is now closed.

Messages (7)
msg69677 - (view) Author: Richard B. Kreckel (richyk) Date: 2008-07-15 10:45
When constructing a floating-point value, literals are apparently
sometimes interpreted as octal integral types, although they contain
exponent marker or/and decimal point. The presence of exponent marker
or/and decimal point should suffice to identify it as floating-point.

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.
msg69695 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-07-15 16:34
I get the same behavior in the trunk (on OS X 10.5), though it's not a 
problem in the py3k branch.

I agree that this is undesirable behaviour, and I think it should be 
fixed.  For me, the crossover seems to occur at 2*10**10:

>>> 020000000000.0
ValueError: invalid literal for long() with base 8: '020000000000.0'
>>> 019999999999.0
19999999999.0
msg69710 - (view) Author: Richard B. Kreckel (richyk) Date: 2008-07-15 19:06
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
Debian stable) and Python 2.5.2 (from Debian testing), both 64 bit
userland. On these systems, the behavior I described does not exist:
Assignment always appears to result in an IEEE754 double-precision float.
msg69722 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-07-15 22:10
> userland. On these systems, the behavior I described does not exist:

Not even with really large values?  What happens on 64-bit with

>>> x = 0800000000000000000000.0

? (that's 20 zeros between the 8 and the decimal point...)
msg69769 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-07-16 09:01
>  >>> x = 0800000000000000000000.0
Urk.  That should be:

>>> x = 01000000000000000000000.0

The problem is in the parsenumber function in Python/ast.c.  The 
solution seems to be very simple:  just remove the entire branch that 
starts with
"if (s[0] == '0')";  that branch is clearly a holdover from pre-Python 
2.4 days when some octal literals were supposed to produce a negative 
int.

Now I just have to figure out where to add tests for this.  Maybe there 
should be a test_float_literal to parallel test_int_literal?
msg69770 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-07-16 09:42
> Now I just have to figure out where to add tests for this.

Found it.  Tests in test_compile.py.

Fixed in the trunk in r65005.  This should probably also be backported to 
2.5.

Thanks for the report, Richard!
msg69771 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-07-16 11:05
Fixed in the 2.5 branch, r65007.
History
Date User Action Args
2008-07-16 11:05:04mark.dickinsonsetstatus: open -> closed
messages: + msg69771
2008-07-16 09:42:04mark.dickinsonsetresolution: fixed
messages: + msg69770
versions: - Python 2.6
2008-07-16 09:01:46mark.dickinsonsetmessages: + msg69769
2008-07-15 22:10:21mark.dickinsonsetmessages: + msg69722
2008-07-15 19:06:12richyksetmessages: + msg69710
2008-07-15 16:34:21mark.dickinsonsetversions: + Python 2.6
nosy: + mark.dickinson
messages: + msg69695
priority: high
assignee: mark.dickinson
type: behavior
2008-07-15 10:45:36richykcreate