Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#9090 closed (invalid)

A problem with WEEKDAYS_ABBR in (Django version 1.0)

Reported by: Leo Putkonen Owned by: nobody
Component: Uncategorized Version: 1.0
Severity: Keywords:, WEEKDAYS_ABBR
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by Karen Tracey)

I noticed this problem while playing around with Django tutorial (part 2).

A button in the admin site interface calls WEEKDAYS_ABBR in and raises ImportError. This happens because WEEKDAYS_ABBR is not defined in located at /site-packages/django/utils/

A simple fix is to add a couple of lines to

    0:_('Mon'), 1:_('Tue'), 2:_('Wed'), 3:_('Thu'), 4:_('Fri'),
    5:_('Sat'), 6:_('Sun')

Complete Traceback:

Django version 1.0-final-SVN-unknown, using settings 'mysite.settings'
Development server is running at
Quit the server with CONTROL-C.
[15/Sep/2008 05:52:08] "GET /admin/ HTTP/1.1" 200 3398
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/servers/", line 277, in run
    self.result = application(self.environ, self.start_response)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/servers/", line 634, in __call__
    return self.application(environ, start_response)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/handlers/", line 239, in __call__
    response = self.get_response(request)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/handlers/", line 128, in get_response
    return self.handle_uncaught_exception(request, resolver, exc_info)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/handlers/", line 148, in handle_uncaught_exception
    return debug.technical_500_response(request, *exc_info)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/views/", line 39, in technical_500_response
    html = reporter.get_traceback_html()
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/views/", line 113, in get_traceback_html
    return t.render(c)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/", line 176, in render
    return self.nodelist.render(context)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/", line 768, in render
    bits.append(self.render_node(node, context))
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/", line 81, in render_node
    raise wrapped
TemplateSyntaxError: Caught an exception while rendering: cannot import name WEEKDAYS_ABBR

Original Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/", line 71, in render_node
    result = node.render(context)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/", line 87, in render
    output = force_unicode(self.filter_expression.resolve(context))
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/", line 559, in resolve
    new_obj = func(obj, *arg_vals)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/", line 626, in date
    from django.utils.dateformat import format
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/utils/", line 14, in <module>
    from django.utils.dates import MONTHS, MONTHS_3, MONTHS_AP, WEEKDAYS, WEEKDAYS_ABBR
ImportError: cannot import name WEEKDAYS_ABBR

Change History (7)

comment:1 Changed 8 years ago by Karen Tracey

Description: modified (diff)
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

comment:2 Changed 8 years ago by Karen Tracey

I'm confused. You're the second person to report this (someone named vijay reported it on the user's list), but WEEKDAYS_ABBR is defined in 1.0 django/utils/

You're saying you don't have the same django/utils/ as you can see on that page?

comment:3 Changed 8 years ago by Leo Putkonen

Thats right!

I downloaded the distribution version of Django 1.0 from this website on September 8th and installed it according to instructions. Now that I looked more closely the tarball includes a correct version of which is quite confusing.

Does this indicate a problem with the installer script for Mac Os X?
Or more likely problems with permissions (before anyone asks I did install as a superuser).

comment:4 Changed 8 years ago by Nudzo

The same problem on my notebook (openSUSE 11.0). from Django-1.0 is different as one in site-packeges directory. It seems that install script is wrong and didn't overwrite old (0.96.x) file. Fixed by manual copying of file from dist tgz to site-packages.

comment:5 Changed 8 years ago by Karen Tracey

Triage Stage: UnreviewedDesign decision needed

Well, the instructions ( do tell you to first uninstall any old level of Django before installing a new level. A clean install would have provided the correct copy of So, technically this is really a user error since Django never claims to be able to install cleanly over a previous copy of itself.

However, I do find the install-over behavior puzzling. Looking just at the django.utils directory, installing 1.0 over 0.96.2, I see 7 of 32 files are not copied. Of those 7 non-copied files 4 (,,, and are identical in 0.96.2 and 1.0, while 3 (,, and are different. (I did not check the remainder of the 32 files to see whether any identical files were copied.) I do not know what criteria the installer is using to decide if a file should be copied, but whatever it is it's producing a weird mutant installation subject to bizarre failures, and that is disturbing. I'd like to see if we can't do something better here. I wonder if there is a way to refuse to install over an existing installation?

If you hit this problem and fixed it by just updating, beware you still don't really have 1.0 installed. You really need to delete the entire old installation and install fresh.

comment:6 Changed 8 years ago by Malcolm Tredinnick

Resolution: invalid
Status: newclosed

I suspect, this comes down to a problem we've discovered elsewhere (and I cannot for the life of me find the right ticket): earlier releases were created with timestamps reflecting the release date, rather than the last-changed date in subversion. The 1.0 release had different timestamps that didn't necessarily update all the files that had changed.

It's unfortunate and potentially confusing, but there's nothing we can really do about it now.

The resolution for this bug is to uninstall the old Django code and install 1.0 afresh so that you're guaranteed to get the new code.

comment:7 Changed 8 years ago by Karen Tracey

#9112 is the other ticket that covers the more general problem. Agreed we can't do anything about 1.0 at this point, but I think we should try to do something for subsequent releases. Always build release tarballs with current date & time and/or refuse to install if an existing install is detected?

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