This is current CVS Python.  Sorry, no idea what caused 
this; it started within the last day (or two at the most):

C:\Code\python\PCbuild>python_d ..\lib\test\test_traceb
ack.py
test_bug737473 (__main__.TracebackCases) ... ERROR
test_caret (__main__.TracebackCases) ... ok
test_nocaret (__main__.TracebackCases) ... ok

==========================================
============================
ERROR: test_bug737473 (__main__.TracebackCases)
------------------------------------------------------
----------------
Traceback (most recent call last):
  File "..\lib\test\test_traceback.py", line 62, in 
test_bug737473
    import test_bug737473
SystemError: NULL result without error in PyObject_Call

------------------------------------------------------
----------------
Ran 3 tests in 0.078s

FAILED (errors=1)
Traceback (most recent call last):
  File "..\lib\test\test_traceback.py", line 90, in ?
    test_main()
  File "..\lib\test\test_traceback.py", line 86, in test_main
    run_unittest(TracebackCases)
  File "C:\Code\python\lib\test\test_support.py", line 
290, in run_unittest
    run_suite(suite, testclass)
  File "C:\Code\python\lib\test\test_support.py", line 
275, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent 
call last):
  File "..\lib\test\test_traceback.py", line 62, in 
test_bug737473
    import test_bug737473
SystemError: NULL result without error in PyObject_Call

[12133 refs]

C:\Code\python\PCbuild>

Logged In: YES 
user_id=31435

Noting that I also see this failure in a release build.

Logged In: YES 
user_id=6656

"Works for me" (linux).  Something Windows specific?

The obviously suspicious recent change is patch #737473
which perky checked in yesterday -- but that was a pure
Python change, so there must be something more to it than that.

Logged In: YES 
user_id=31435

Sorry to hear that -- I can't make time to dig.  I blew away 
everything and recompiled from scratch, and the problem 
didn't go away.

Logged In: YES 
user_id=31435

Reduced the priority, because test_bug737473() raises the 
same SystemError under the released Python 2.3.4 on my 
box -- it's not a new problem.  OTOH, we can't release 2.4 
with a standard test that fails on a major platform either.

Logged In: YES 
user_id=55188

I failed to reproduce the problem in FreeBSD, Windows XP and
Linux.  What's your platform testing in?

Logged In: YES 
user_id=31435

I'm on WinXP Pro SP2.

Logged In: YES 
user_id=31435

Looks damn complicated.  In import.c, load_source_module() 
returns NULL if PyOS_GetLastModificationTime() returns -1.  
But PyOS_GetLastModificationTime() doesn't set any 
exception when it does return -1.  This NULL then propagates 
all the way back to PyObject_Call(), which produces the 
SystemError I see.

So there's at least a bug in load_source_module() here -- it 
can't return NULL without setting an exception.

I don't yet know why PyOS_GetLastModificationTime() 
returns -1 in this test case.  I suspect it's because the (0,0) 
passed to utime() doesn't make much sense.  I don't get the 
error if I force it to take the time.sleep() path instead.

Logged In: YES 
user_id=31435

Reduced priority to 5 (default).  Papered over the bug by 
passing sane values to os.utime() in the new test code.  The 
underlying import.c bug is still there.

Logged In: YES 
user_id=31435

Changed the description to match current reality, and 
changed group to Python 2.3 (the import.c bug is an old 
bug).  I don't intend to work on it.

Logged In: YES 
user_id=31435

FYI, any value passed to utime less than 18000 causes the 
problem on my box, and  I bet it's not a coincidence that I'm 
currently 5 hours (18000 seconds) west of the prime meridian.

Logged In: YES 
user_id=33168

load_source_module() sets an error now.  Assuming everything
is working as it should.  Tim, re-open if there's any work
left to do on this.