Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#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 awatts, 15 years ago

I just noticed that after that traceback there's a 2nd one:

Original Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/template/debug.py", line 71, in render_node
    result = node.render(context)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/template/debug.py", line 87, in render
    output = force_unicode(self.filter_expression.resolve(context))
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/template/__init__.py", line 572, in resolve
    new_obj = func(obj, *arg_vals)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/template/defaultfilters.py", line 681, in date
    from django.utils.dateformat import format
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/utils/dateformat.py", line 18, in <module>
    from django.utils.tzinfo import LocalTimezone
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/utils/tzinfo.py", line 5, in <module>
    from django.utils.encoding import smart_unicode, smart_str, DEFAULT_LOCALE_ENCODING
ImportError: cannot import name DEFAULT_LOCALE_ENCODING

comment:2 by awatts, 15 years ago

Version: 1.0SVN

comment:3 by Karen Tracey, 15 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 Alex Gaynor, 15 years ago

Resolution: worksforme
Status: newclosed

No new information after 2 months, I'm going to close as worksforme.

comment:5 by yopi, 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.

in reply to:  5 ; comment:6 by Karen Tracey, 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?

in reply to:  6 ; comment:7 by mertnuhoglu, 14 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.

in reply to:  7 comment:8 by anonymous, 14 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.

Note: See TracTickets for help on using tickets.
Back to Top