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
-- http://mail.python.org/mailman/listinfo/python-list
