Named imports in urls

[Filip Gruszczyński]

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/tests.py", line 194, in test_edit_sent_ticket_post_staff_only

response = client.post(address, dictionary)

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

return self.request(r)

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

response = self.handler(environ)

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

response = self.get_response(request)

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

return self.handle_uncaught_exception(request, resolver, exc_info)

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

callback, param_dict = resolver.resolve500()

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

return self._resolve_special('500')

File "/var/lib/python-support/python2.6/django/core/urlresolvers.py", 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?

[rvdrijst]

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.

[Filip Gruszczyński]

Indeed, I screwed. I removed * from import in urls.py, 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.

[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 urls.py, 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 *?

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

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

[Filip Gruszczyński]

patch for urls.py template file

[Chris Beaven]

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)