Opened 7 years ago

Closed 7 years ago

#11013 closed (invalid)

Named imports in urls

Reported by: Filip Gruszczyński Owned by: nobody
Component: Core (Other) Version: 1.1-beta
Severity: Keywords:
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: UI/UX:


Every time there is an exception during testing (inside the tested code, not the tests), the only thing I get is:

Traceback (most recent call last):

File "/home/gruszczy/Programy/bozorth/../bozorth/issues/", line 194, in test_edit_sent_ticket_post_staff_only

response =, dictionary)

File "/var/lib/python-support/python2.6/django/test/", line 292, in post

return self.request(r)

File "/var/lib/python-support/python2.6/django/test/", line 217, in request

response = self.handler(environ)

File "/var/lib/python-support/python2.6/django/test/", line 64, in call

response = self.get_response(request)

File "/var/lib/python-support/python2.6/django/core/handlers/", line 128, in get_response

return self.handle_uncaught_exception(request, resolver, exc_info)

File "/var/lib/python-support/python2.6/django/core/handlers/", line 159, in handle_uncaught_exception

callback, param_dict = resolver.resolve500()

File "/var/lib/python-support/python2.6/django/core/", line 218, in resolve500

return self._resolve_special('500')

File "/var/lib/python-support/python2.6/django/core/", line 207, in _resolve_special

callback = getattr(self.urlconf_module, 'handler%s' % view_type)

AttributeError: 'module' object has no attribute 'handler500'

This gives me very little information about what happened inside. Is there any chance to pass more information, when such an exception occurs?

Attachments (1) (418 bytes) - added by Filip Gruszczyński 7 years ago.
patch for template file

Download all attachments as: .zip

Change History (9)

comment:1 Changed 7 years ago by rvdrijst

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Resolution: invalid
Status: newclosed

I had the same problem but it turned out to be me, not django.

My problem was that I was using a custom urls attribute in the testcase but I didn't specify a handler404 and handler500 in addition to a urlpatterns. There are three solutions to this:

  • specify handler404 and handler500 after the urlpatterns, referencing existing (dummy) views (see the docs),
  • import the default handlers by doing from django.conf.urls.defaults import * (will require a 404.html and 500.html template, also see the docs) ,
  • set DEBUG to True during testing (which may require a little hacking and is not recommended, see these docs).

I'm closing this ticket, assuming these suggestions do indeed solve your problem, but feel free to reopen if your problem persists.

comment:2 Changed 7 years ago by Filip Gruszczyński

Component: Testing frameworkUncategorized
Resolution: invalid
Status: closedreopened
Summary: Better diagnostics information while testingNamed imports in urls

Indeed, I screwed. I removed * from import in, because using all on import is not recommended - but I had no idea, that Django is going to use some other objects from this import (they are not mentioned anywhere in the file).

I believe, that all imports there should be named, so the user knows, that there are some required objects imported.

comment:3 Changed 7 years ago by Thejaswi Puthraya

Component: UncategorizedCore framework

comment:4 Changed 7 years ago by lacker

Wow, I ran into this too. I was quite surprised that "from django.conf.urls.defaults import *" has side effects involving functions that are imported but not visibly used. It seems unpythonic, since the standard python advice is to avoid importing * whenever possible. For example, whenever I write code in my, I run the risk of squashing or accidentally referring to variables that got introduced in the import. Would it be possible to make this work without the import *?

comment:5 in reply to:  4 Changed 7 years ago by Ramiro Morales

Replying to lacker:

Wow, I ran into this too. I was quite surprised that "from django.conf.urls.defaults import *" has side effects involving functions that are imported but not visibly used.

What do you mean with visibly used?

comment:6 Changed 7 years ago by anonymous

He means, that handler404 and handler500, which are imported in urls module, aren't explicitly used there. The code that creates urls, should create file with:

from django.conf.urls.defaults import patterns, include, handler500, handler404

I can try to code this and post a patch.

Changed 7 years ago by Filip Gruszczyński

Attachment: added

patch for template file

comment:7 Changed 7 years ago by Filip Gruszczyński

Has patch: set
Needs tests: set

comment:8 Changed 7 years ago by Chris Beaven

Resolution: invalid
Status: reopenedclosed
Triage Stage: UnreviewedDesign decision needed

I agree that the current urlconf method relies on an overly implicit import. The original ticket here is for a different issue, which was indeed invalid.

Feel free to open a new ticket with a suggestion on how to avoid this reliance on implicit imports (and/or bring up the issue in the django dev google group)

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