Thanks for the explanation, but I still don't understand why it doesn't work with function references.
For one, http://docs.djangoproject.com/en/dev/topics/http/urls/#reverse says "viewname is either the function name (either a function reference, or the string version of the name, if you used that form in urlpatterns)", and the underlying dict for reverse() uses the function references as keys wether you call by string or function reference, right? Do get the same callable no matter how you import the function or does this not tell the whole story: >>> import facesearch.views >>> from facesearch.views import start_search >>> facesearch.views.start_search == start_search True You're probably right that using "name=..." is the best solution, but it seems inelegant to me - for the case of one urlpattern per view, a reference to that view should be a perfectly unambiguous way to specify which urlpattern you want. Though I'm probably missing some piece of the picture and there's an implementation detail that screws this up. Cheers, Ian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Malcolm Tredinnick Sent: Friday, 16 January 2009 12:25 PM To: [email protected] Subject: RE: reverse() problems (NoReverseMatch) It does work either way, although function references are a bit more fragile, since the "name" of the function reference varies a bit depending upon how it's imported. However, the real problem was in your first message. You wrote: >>> from django.core.urlresolvers import reverse >>> from facesearch.views import start_search >>> reverse(start_search) The reverse() function expects a string as its first argument. You're passing a function object. That line kind of only worked by accident (well, it didn't work at all, but it looked like it did). Pass in a string and things will go much better. Of course, then you're more likely to hit the problem with trying to match the function name exactly as imported, so it's better to use the "name=..." version of URL patterns as it's more robust and tends to lead to cleaner code. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
