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.