I'll try and update my library over the next couple of days to also support 
regex fragments and converters supporting parameters.

Another part I see is that the high coupling between Django and the URL 
resolvers (as mentioned in 
http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ ) should 
probably be cleaned up, if it is desired to someday support alternative URL 
resolvers. I'm willing to provide a patch for the checking part, but I'm 
not sure if it would be accepted. Do I need to open a ticket for that?

Kind regards,
Sjoerd Job

On Thursday, September 22, 2016 at 2:09:53 PM UTC+2, Tom Christie wrote:
> Wanted to add my support for this.
> Personally I'd be totally in favour of considering something along these 
> lines for core, once there's a fully proven design.
> The capture syntax is:
> * Far simpler.
> * Meets pretty much every single real-world case I ever see.
> * Gives us type coercion.
> * Also able to support regex fragments if needed. Eg see 
> http://stackoverflow.com/questions/5870188/does-flask-support-regular-expressions-in-its-url-routing
> Given that we could continue to keep the existing style around as well, 
> this is an area where I'd be happy to see Django take a step forward.
> Sticking with the path->existing regex mapping implementation sounds like 
> the best tack, at least initially, rather than getting bogged down in API 
> discussions around how we'd tackle a routing API if we wanted to support 
> non-path routing.
> Cheers,
>   Tom

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.

Reply via email to