Before I looked into the code, I found this really hard to believe. In my
mind, the whole resolving framework would be built upon classes providing
`resolve` and `reverse` methods. I was only partially right. I looked into
it a bit more and wrote up my conclusions
here: http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ .
- The URL routing is mostly loosely coupled, with the exception of the
`checks` and the `reverse` method. Furthermore, the `RegexURLResolver` is
coupled to the idea that all sub-resolvers/patterns are also regex-based.
- By moving the `check` responsibility to the resolvers (same as with
model-checks) and `reverse` responsibility to the resolvers as well, the
coupling is lowered, and we would actually be able to switch in a
completely different set of resolvers.
- It might be a good idea to make `RegexURLResolver.reverse` agnostic of
Is there any form of coupling I missed?
On Friday, September 16, 2016 at 2:57:24 PM UTC+2, ludovic coues wrote:
> In my opinion, there is two point. First, core django should allow
> different url resolver. Second, these different url resolver should
> start as third party package.
> Without first point, people need to hack django if they want to
> experiment new kind of resolver. Like one providing typecasting or a
> faster one or a localized one. And the resolver isn't "loosely
> coupled" unlike most of the other part of django.
> For the second point, I have a simple reason. Choosing between the
> rail or the werkzeug syntax is bike shedding. It is not a technically
> choice. It's an aesthetic one. There is no right answer, only lost
> 2016-09-16 9:30 GMT+02:00 Curtis Maloney <cur...@tinbrain.net
> > On 15/09/16 16:37, Curtis Maloney wrote:
> >> Somewhere I have code to provide a "parse" based URL router.
> >> Will dig it up now 1.10 has has shipped
> > Ah, found it...
> > So, here is a gist of a sample of using parse
> > (https://pypi.org/project/parse/) instead of regex.
> > https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b
> > Since you can register extra type names, and those types can cast also,
> > covers a lot of things some people expect [but don't get] from regex.
> > --
> > C
> >> On 14 September 2016 6:38:20 PM AEST, Florian Apolloner
> >> Hi Emil,
> >> On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström
> >> wrote:
> >> and more experienced users are expected to switch over to using
> >> regexes directly to get the exact behavior they want.
> >> How so? Personally I would use this quite quickly since a few
> >> builtin types would cover 99%. While I can write regex in sleep
> >> nowadays, I still find it kinda tedious to redefine what "slug"
> >> means in every URL I wanna match something… I am sure others think
> >> the same.
> >> Beginners likely won't look at all the different options and
> >> choose one based on it's merits, they'll pick whatever their
> >> teacher suggests they use. Also installing an extra package
> >> setting up django feels a bit strange.
> >> I think the eco system is far enough to support that, after all
> >> south lived long and well as external package. Either way, DEP or
> >> not, having an implementation out there would definitely help.
> >> Cheers,
> >> Florian
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.