Made URL application namespaces be set in the included URLconf and
instance namespaces in the call to include(). Deprecated other ways
to set application and instance namespaces.
When reversing, only outer parameters are used if captured parameters are
nested. Added tests to check the edge cases and documentation for the
behavior with an example to avoid it.
Tests were using an undocumented keyword argument for easily overriding
script prefix while reversing. This is now changed into a test utility
which can be used as decorator or context manager.
Prefix was treated as a part of the url pattern, which it is not.
Improved tests to conform with RFC 3986 which allows certain
characters in path segments without being escaped.
Propagated unnamed arguments as positional arguments into included
URLconfs if no named arguments are defined. Positional and keyword
arguments are never combined.
And follow more closely the class of characters defined in the
RFC 3986.
Thanks Erik van Zijst for the report and the initial patch, and
Tim Graham for the review.
- Fixed bug in get_callable() that caused resolve() to put a string
in ResolverMatch.func.
- Made ResolverMatch.url_name match the actual url name (or None).
- Updated tests that used the string value in ResolverMatch.func, and
added regression tests for this bug.
- Corrected test urls whose dummy view paths caused failures (behavior
that was previously masked by this bug).
Fixed URL resolving in the case where an outer regex includes an inner
regex and both regexes use positional parameters instead of named
groups, causing the outer regex's parameters to override the inner
regex's.
Modified the regex url resolver so that it will concatenates and then
normalizes, instead of normalizing and then concatenating.
The new error message now hints that the most likely issue
is a circular import.
Thanks to trac user elena for the report and to
bpeschier for the original patch.
Commit 79558c78 cleaned up the (undocumented) interface of Resolver404
exception, which breaks compatibility with code messing with .args[0]
directly. Revert the cleanup part and simply leave the fix itself.
When django.core.urlresolvers.resolve was called from a view, failed
and the exception was propagated and rendered by technical_404_response,
the URL mentioned on the page was the current URL instead of the URL
passed to resolve().
Fixed by using the path attribute from the Resolver404 exception instead
of request.path_info. Also cleaned up the exceptions to use standard
named parameters instead of stuffing a dict in args[0]
