> E.g., flask uses a simple `<int:id>` to match an integer and capture it in the `id` parameter. Support to check for conflicts would be a lot simpler with those patterns. It would definitely be a best-effort feature.
>From my point of view, this by itself would make for a really nicely-scoped GSoC project. Being able to demonstrate an API that allowed the user to switch to a URL resolver that used that simpler style would be a really, really nice feature, and also feels like it might actually be a manageable amount of work. This wouldn't *necessarily* need to allow decorator style routing, instead of the current URLConf style, but that might also be a nice addition. Personally though I would consider tackling that as an incremental improvement. Things I'd be wary of: * Anything around "continue resolving" exceptions or object inspection during routing, both of which sound like an anti-pattern to me. * Method based routing. Feel less strongly about this, but still not convinced that it's a good style. * Generic views / model routes / automatic routing. Too broadly defined, and with no clear best answer. Anyways, interesting stuff Marten, look forward to hearing more. 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bc559676-60d9-48e1-bbe0-7abb52397184%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.