curious problem with large numbers

[Michael Spencer]

Scott David Daniels wrote:
> Steve Holden wrote:
> 
>> Scott David Daniels wrote:
>>
>>> Terry Reedy wrote:
>>>
>>>> On my Windows machine with 2.2.1, I get exactly what you expected:
>>>>
>>>>>>> 1e10000
>>>>
>>>>
>>>> 1.#INF
>>>> ...
>>>> If you get wrong behavior on a later version, then a bug has been 
>>>> introduced somewhere, even perhaps in VC 7, used for 2.4.
>>>
>>>
>>> Nope, it is also there for 2.3.4 (May 25 2004, 21:17:02)....
>>
>>
>> A further Windows data point from Cygwin:
>>
>> Python 2.4 (#1, Dec  4 2004, 20:10:33)
>> [GCC 3.3.3 (cygwin special)] on cygwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>  >>> 1e10000
>> Inf
>>  >>>
>>
>> regards
>>  Steve
> 
> 
> Aha! Same version (2.3.4):
> 
> Idle:
>     >>> 1e10000
>     1.0
>     >>> import struct; struct.pack('d', 1e10000)
>     '\x00\x00\x00\x00\x00\x00\xf0?'
> (which is actually 1.0)
> 
> python via command line (readline support):
>     >>> 1e10000
>     1.#INF
>     >>> import struct; struct.pack('d', 1e10000)
>     '\x00\x00\x00\x00\x00\x00\xf0\x7f'
> 
> Note the difference in the final byte.  Same results (command
> line vs. Idle) for 2.4.1.
Good catch!  Same for me:

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.

...

IDLE 1.1
 >>> 1e10000
1.0

and note this happens only at the IDLE interactive interpreter:
  >>> import testidleinf
1.#INF
(where testidleinf is "print 1e10000")

On a quick inspection, it seems that IDLE just passes the input to 
code.InteractiveInterpreter (after removing tabs and normalizing EOL), but 
calling code.InteractiveInterpreter directly does not reproduce the error...

(still in IDLE at the interactive prompt):

  >>> from code import InteractiveInterpreter
  >>> II = InteractiveInterpreter()
  >>> II.runsource("1e10000")
1.#INF
  False
  >>>

hmmm...

Michael