Exception Raised: TypeError: Initialization arguments are not supported

[dejones]

When using google-app-engine-django with django at revision 10386, I tried to execute "python manage.py runserver" but an exception was raised, "TypeError: Initialization arguments are not supported."

I have attached the full log output, relevant log snippet:

File "/home/darthik/darthik-com/django/db/init.py", line 57, in <module>

'TIME_ZONE': settings.TIME_ZONE,

File "/home/darthik/lib/python2.5/_threading_local.py", line 159, in new

raise TypeError("Initialization arguments are not supported")

TypeError: Initialization arguments are not supported

System info:

Python 2.5.4
Linux apocalypse 2.6.24.5-xeon-aufs20081006-grsec #1 SMP Thu Oct 9 15:42:59 PDT 2008 x86_64 GNU/Linux
Django svn at revision 10386

NOTE: This exception is not raised when I use Django-1.0.2-final.

[dejones]

Output from google-app-engine-django, python manage.py runserver

[Ramiro Morales]

This a google-app-engine-django bug:

​http://code.google.com/p/google-app-engine-django/issues/detail?id=119

it seems the DB backend hasn't been updated to be compatible with changes made in Django r10026

PS: I don know if that project strives to be compatible with a moving target like Django trunk at all, maybe it is safer to use a released 1.0.x version or to switch to another GAE compatibility helper that follows Django trunk more closely like app-engine-patch.

[bsergean]

If I sync django to revision 10025 it works fine.

cd google_appengine/lib
mv django django-old
svn export -r 10025 /svn/path/to/django-trunk django

[Andi Albrecht]

The appengine helpers DB backend is fine.
Actually it's a Python bug (​http://bugs.python.org/issue1522237) in _threading_local. It came up here, because the App Engine environment uses _threading_local.local and not thread._local as Django would do in a normal setup (e.g. the thread module is available).

I'm not sure if there are other Django setups, that use the _threading_local implementation too. At least there is some potential as the thread module is marked as optional in the Python docs. If so, all backends should fail in that case (according to Guido's comment on the Python tracker, the fix for this bug will not go into Python version < 2.6 and ATM it's even not applied in trunk).

It's pretty easy to "reproduce" this behavior for Django's builtin backends by monkey patching threading.local somewhere at the top of manage.py, for example:

# manage.py
import threading
import _threading_local
threading.local = _threading_local.local

[...]

[Andi Albrecht]

Patch to check the presence of the thread module to avoid using the buggy _threading_local.local implementation

[termie]

reopening this, as this is is still in Django 1.1 and affects all backends using the python version of _threading_local module (any env without a thread module) and explicit steps have been made in other parts of the code ( ​http://code.djangoproject.com/changeset/10096 ) to deal with the repercussions of this as affected by python 2.3, however in python 2.4 the patched django version of the file is never used as the threading module will use the built-in python version.

the attached patch "thread_local_import.diff" works fine for fixing this.

[Jacob]

After 1.1 we're no longer supporting Python 2.3, so this is wontfix.

[Karen Tracey]

Replying to jacob:

After 1.1 we're no longer supporting Python 2.3, so this is wontfix.

It isn't entirely clear, but I don't think temie's comment was indicating this is only a problem for people running Python 2.3. Rather the way I read temie's comment, this is a problem on Pythons 2.4+. We've got a patched threading module that fixes it, and that is used for 2.3, but that module won't be used for Python 2.4+ since we think it's not necessary. Malcolm's comment in r10096 in making the fix mentions not understanding why the problem hasn't been observed on 2.4+. It sounds like GAE may be an environment where it can be observed.