Exceptions are raised when terminating the development server with USE_I18N = False

[bahamut@…]

The following exception tracebacks are printed when terminating or reloading the development server with USE_I18N = False. When that setting is set to True, those exceptions do no occur.

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py", line 638, in __exitfunc
    self._Thread__delete()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py", line 522, in __delete
    del _active[_get_ident()]
KeyError: -1610551912
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py", line 638, in __exitfunc
    self._Thread__delete()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py", line 522, in __delete
    del _active[_get_ident()]
KeyError: -1610551912

I am running Django from Subversion trunk on Mac OS X 10.4.7 PPC, python 2.4 (from DarwinPorts).

[Adrian Holovaty]

Thanks for reporting this. I'd been noticing it myself but didn't know why it was happening. I've verified that it happens only with USE_I18N=False. Any ideas?

[Adrian Holovaty]

I've found a fix to the problem: Put this in django/utils/autoreload.py after the 4 import thread lines --

try:
    import threading
except ImportError:
    pass

This is hackish, but it appears to fix the problem for me. Thoughts?

[Malcolm Tredinnick]

It looks like a race condition: looking in the comment at the top of threading.Thread.__delete, you can see why the key error is happening, but not how we are causing it. Still, it's only the dev server, so a bit of sticky-tape to fix it won't kill us. It's still a pretty mysterious fix for the problem.

[anonymous]

Inserting Adrian's suggestion into django/utils/translation/trans_null.py right after from django.conf import settings also stops the error message. Maybe it's a more logical place to put it, due to the cause of the error.. even if I'm not sure _why_ it works ; )

[anonymous]

I've noticed that if you remove the

USE_I18N = False

varable from settings.py it doesn't appear.

[Adrian Holovaty]

(In [3482]) Fixed #2330 -- Added hack to stop KeyErrors from being thrown by the autoreloading development server if USE_I18N=False

[Adrian Holovaty]

For the record, I added the hack because having that KeyError display on server quit is unacceptable.