#11081 closed (worksforme)
Page rendering fails after upgrading to r10703
Reported by: | awatts | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Keywords: | getdefaultlocale mac | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I did and svn update the other day and the changes made in source:/django/trunk/django/utils/encoding.py in changeset:10703 to fix ticket:10335 seems to be causing all template renderings to fail for me with a traceback like the following:
Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/core/servers/basehttp.py", line 278, in run self.result = application(self.environ, self.start_response) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/core/servers/basehttp.py", line 636, in __call__ return self.application(environ, start_response) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 241, in __call__ response = self.get_response(request) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/core/handlers/base.py", line 134, in get_response return self.handle_uncaught_exception(request, resolver, exc_info) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/core/handlers/base.py", line 154, in handle_uncaught_exception return debug.technical_500_response(request, *exc_info) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/views/debug.py", line 40, in technical_500_response html = reporter.get_traceback_html() File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/views/debug.py", line 114, in get_traceback_html return t.render(c) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/template/__init__.py", line 178, in render return self.nodelist.render(context) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/template/__init__.py", line 779, in render bits.append(self.render_node(node, context)) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/template/debug.py", line 81, in render_node raise wrapped TemplateSyntaxError: Caught an exception while rendering: cannot import name DEFAULT_LOCALE_ENCODING
I'm running MacOS X 10.5.6 with Python 2.6 and using the SVN version of Django.
Change History (8)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Version: | 1.0 → SVN |
---|
comment:3 by , 16 years ago
I saw this exception when I did an svn up
of the code in use by a running dev server. Restarting the dev server fixed it. I assume you have tried restarting the server? And verified that the code you are running has the definition of DEFAULT_LOCALE_ENCODING
in the django/utils/encoding.py?
comment:4 by , 15 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
No new information after 2 months, I'm going to close as worksforme.
follow-up: 6 comment:5 by , 15 years ago
Had the same issue when upgrading to 11724. The error is explicit tho, DEFAULT_LOCALE_ENCODING has to be set to UTF-8. I use mod_fastcgi with a socket so I could use:
/usr/bin/env - \
DEFAULT_LOCALE_ENCODING="UTF-8" \
PYTHONPATH="../python:.." \
./manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE maxrequests=1
However, Django is making an assumption here about DEFAULT_LOCALE_ENCODING that wasn't made before. This is an unfortunate change that deserves a fix. There are no doubts that lots of user are uselessly reunning into that error.
follow-up: 7 comment:6 by , 15 years ago
Replying to yopi:
I don't understand what you are trying to say. DEFAULT_LOCALE_ENCODING is calculated in django/utils/encoding.py:
http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/utils/encoding.py#L142
The original problem reported here was that the name DEFAULT_LOCALE_ENCODING could not be imported from there, for reasons that were never tracked down due to lack of information from anyone who could consistently recreate the problem (I saw it once, but it went away after a server restart). If you can consistently recreate this problem:
from django.utils.encoding import smart_unicode, smart_str, DEFAULT_LOCALE_ENCODING ImportError: cannot import name DEFAULT_LOCALE_ENCODING
then some information on how that happens would be helpful, since I don't see how it can happen given the way it is calculated.
If you do not like what is getting calculated for DEFAULT_LOCALE_ENCODING, then that's a different issue and deserves its own ticket. The changeset that introduced it fixed a real problem on some systems, where Python raised an exception attempting to get the encoding for the default locale. If it is causing another problem in other configurations, then we need more specific information about what that problem is in order to fix it. "Django is making an assumption here about DEFAULT_LOCALE_ENCODING that wasn't made before" is too vague to be helpful -- what assumption? The current code tries its best to determine a good value without ever raising an exception -- how would you propose to change that to fix whatever problem you are seeing, and still fix the problem fixed by r10703, which introduced DEFAULT_LOCALE_ENCODING?
follow-up: 8 comment:7 by , 15 years ago
Replying to kmtracey:
django 1.1.1 final version which is available for download in the website doesn't contain the lines that calculate DEFAULT_LOCALE_ENCODING.
comment:8 by , 15 years ago
Replying to mertnuhoglu:
Replying to kmtracey:
django 1.1.1 final version which is available for download in the website doesn't contain the lines that calculate DEFAULT_LOCALE_ENCODING.
Yes, it does, really. It contains exactly the code you can see on the website here:
http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/utils/encoding.py#L142
I just downloaded a fresh copy, unpacked, and checked the file. The code is there in the release file.
I just noticed that after that traceback there's a 2nd one: