Reverse for '<django.contrib.auth.decorators._CheckLogin object at 0x8ee144c>' not found

[imbaczek@…]

this happens when trying to get a reverse for a function decorated with @login_required.

[oyvind]

this is for django development, not support requests, use named urls instead

[Werner Beroux]

Replying to oyvind:

this is for django development, not support requests, use named urls instead

What's that supposed to mean? Is @login_required or reverse() for development only? What do you mean by "use named urls"; do you mean hard coding the full URL making the application to a force URL?

I got the same problem on Django 1.02 final

[Alex Gaynor]

What oyvind meant was that this is known to work in Django, trac is not for support requests, that's what the mailing list and IRC are for.

[ogdoad8]

I was getting this error when passing a floating point numeric variable (by accident) instead of a string variable as the view argument in my {% url view.here variable %}.
Hopefully this comment will help somebody.

In this case, this was probably the most unhelpful error I've ever seen! Am re-opening so that maybe some type-checking can be done in Django to make for a more helpful error message.

You can reproduce this by passing a floating point value (ints don't trigger this) to a template and using that variable as a view argument that's expecting a string.

[Karen Tracey]

Replying to ogdoad8:

In this case, this was probably the most unhelpful error I've ever seen! Am re-opening so that maybe some type-checking can be done in Django to make for a more helpful error message.

This is a bit too vague to be useful as a suggested improvement. Type-checking what, exactly?

You can reproduce this by passing a floating point value (ints don't trigger this) to a template and using that variable as a view argument that's expecting a string.

Again, you've left out a lot of details so I have to guess what pattern you might be using, etc. Guessing you have a pattern like:

    (r'^thing/(?P<pk>\d+)/$', 'thing_detail'),

If you then try in a template:

  {% url thing_detail magic_number %}

where magic_number is a float variable in the context, the attempt to reverse will fail because the string representation of the float will have a decimal point in it, thus will not patch the \d+ pattern. Integers work because their string representation matches the pattern. But it would be perfectly legitimate to have a url pattern that did match the string representation of a float, so it isn't like the url tag can arbitrarily reject float arguments. The best it can do is say there is no pattern that matches what you've passed it.

If you've got a specific suggestion for improvement feel free to open a new ticket with recreation details including exactly what you are doing, what message you get, what you think would be better, and how you think Django could actually accomplish that. So far as I can tell what you are asking for here is not something that is possible.

[Luke Plant]

It would be much more helpful if the error message said <path.to.your.view.function> rather than <django.contrib.auth.decorators._CheckLogin object at 0x8ee144c>. I'll have a look at doing this.

[Luke Plant]

See r11482. (For some reason a comment was not automatically posted here). I don't know if this addresses your problem, but it might help.

[Alexander Schepanovski]

Actual problem is not wrapping view carefully, I used my own decorator which used functools.wraps decorator to wrap wrapper function and view function
was reported right in reverse error.

[Luke Plant]

Suor - I don't understand your comment or why you reopened the ticket. Currently all our decorators use functools.wraps (or equivalent) as far as I know, and the view functions are now reported correctly in the NoReverseMatch error. Also, before r11482 it was not enough simply to use correct wrapping, because callables like _CheckLogin (or MethodDecoratorAdaptor) would still display the unhelpful message given above. Or did you re-open by mistake?

[Alexander Schepanovski]

Sorry, for reopening. I am using 1.1 release where error message is still incorrect.