Code

Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#11081 closed (worksforme)

Page rendering fails after upgrading to r10703

Reported by: awatts Owned by: nobody
Component: Core (Other) Version: master
Severity: Keywords: getdefaultlocale mac
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

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.

Attachments (0)

Change History (8)

comment:1 Changed 5 years ago by awatts

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 Changed 5 years ago by awatts

  • Version changed from 1.0 to SVN

comment:3 Changed 5 years ago by kmtracey

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 Changed 5 years ago by Alex

  • Resolution set to worksforme
  • Status changed from new to closed

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

comment:5 follow-up: Changed 4 years ago by yopi

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.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 4 years ago by kmtracey

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?

comment:7 in reply to: ↑ 6 ; follow-up: Changed 4 years ago by 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.

comment:8 in reply to: ↑ 7 Changed 4 years ago by anonymous

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.