Opened 15 years ago

Closed 15 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: no UI/UX: no

Description

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?

Attachments (1)

urls.py.diff (418 bytes ) - added by Filip Gruszczyński 15 years ago.
patch for urls.py template file

Download all attachments as: .zip

Change History (9)

comment:1 by rvdrijst, 15 years ago

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 by Filip Gruszczyński, 15 years ago

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

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.

comment:3 by Thejaswi Puthraya, 15 years ago

Component: UncategorizedCore framework

comment:4 by lacker, 15 years ago

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

in reply to:  4 comment:5 by Ramiro Morales, 15 years ago

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 by anonymous, 15 years ago

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.

by Filip Gruszczyński, 15 years ago

Attachment: urls.py.diff added

patch for urls.py template file

comment:7 by Filip Gruszczyński, 15 years ago

Has patch: set
Needs tests: set

comment:8 by Chris Beaven, 15 years ago

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