This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

Logged In: YES 
user_id=21627

Closing this as "not a bug". Notice that this judgement is
difficult to make, as the report is incomplete: you report
what you did (good), what happened (good), but not what you
expected to happen, or why you think the behaviour is
incorrect - only that it is "weird". As Tim mentioned
indirectly, this is intentional.

Logged In: YES 
user_id=6656

Also, this probably won't be a problem in 2.5.

Logged In: YES 
user_id=31435

mwh:  Heh.  It's sure not better under Windows on current trunk:

C:\Code\python\PCbuild>python -c "import nan"
-1.#IND
Exception exceptions.SystemError: 'frexp() result out of
range' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage
collection

And now that the .pyc file exists:

C:\Code\python\PCbuild>python -c "import nan"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: bad marshal data

This is nan.py, BTW:

"""
inf = 1e300000
nan = inf/inf
print nan
"""

Changing that to "inf = 1e300*1e300" doesn't help in the
trunk, because of its more ambitious constant folding.

Logged In: YES 
user_id=6656

Huh what?  That code is supposed to be dead on real systems now.  What does 
this say for you:

>>> float.__getformat__('double')
'IEEE, big-endian'

?  I take it test_float still passes.

Logged In: YES 
user_id=31435

Hmm:

C:\Code\python\PCbuild>python
Python 2.5a2 (trunk:46052, May 19 2006, 20:53:33) [MSC
v.1310 32 bit (Intel)] on win32
>>> float.__getformat__('double')
'unknown'

Logged In: YES 
user_id=31435

BTW, I suspect SIZEOF_DOUBLE simply isn't defined on
Windows.  I'll check that later.

Logged In: YES 
user_id=6656

Oh right.

The "Fatal Python error: unexpected exception during garbage collection" thing 
is still a bit disturbing though...