A problem with WEEKDAYS_ABBR in dates.py (Django version 1.0)

[Leo Putkonen]

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

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

A simple fix is to add a couple of lines to dates.py

WEEKDAYS_ABBR = {
    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 http://127.0.0.1:8000/
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/basehttp.py", 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/basehttp.py", 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/wsgi.py", 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/base.py", 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/base.py", 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/debug.py", 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/debug.py", 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/__init__.py", line 176, in render
    return self.nodelist.render(context)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", 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/debug.py", 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/debug.py", line 71, in render_node
    result = node.render(context)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/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.5/lib/python2.5/site-packages/django/template/__init__.py", 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/defaultfilters.py", 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/dateformat.py", line 14, in <module>
    from django.utils.dates import MONTHS, MONTHS_3, MONTHS_AP, WEEKDAYS, WEEKDAYS_ABBR
ImportError: cannot import name WEEKDAYS_ABBR

[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/dates.py:

​http://code.djangoproject.com/browser/django/tags/releases/1.0/django/utils/dates.py#L9

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

[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 dates.py 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).

[Nudzo]

The same problem on my notebook (openSUSE 11.0). dates.py 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.

[Karen Tracey]

Well, the instructions (​http://docs.djangoproject.com/en/dev/intro/install/#remove-any-old-versions-of-django) 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 dates.py. 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 (__init__.py, _threading_local.py, termcolors.py, and xmlutils.py) are identical in 0.96.2 and 1.0, while 3 (dates.py, stopwords.py, and synch.py) 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 dates.py, beware you still don't really have 1.0 installed. You really need to delete the entire old installation and install fresh.

[Malcolm Tredinnick]

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.

[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?