> 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.

Reply via email to