homepage

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.

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

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.

> 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...)

> >>> 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?

> 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!

Fixed in the 2.5 branch, r65007.