I actually do have working code that among other things abstracts the
regex to a Constraint, which allows you to easily inject your own custom
logic for resolving and reversing url fragments. This allows for a "simple"
system at a more fundamental level, rather than just translating the
"simple" system to a regex-based system. It has full support for routing on
any property of the request. The code is mostly in a finished state, and
the public API is fully backwards compatible, though there are a few small
changes in Django's current master that'll have to be merged manually or
rewritten. The biggest hurdle is that it still doesn't have any
I'm afraid I don't have the time to finish it by myself at the moment, as
I'm juggling work, a new bachelor (computer science!) and other activities.
I'd like to continue and finish my work when I have the time (and
motivation), but if someone were to step in where I left off, I'd be happy
to provide any assistance required.
On Friday, September 16, 2016 at 7:49:45 AM UTC+2, Marc Tamlyn wrote:
> Fwiw, I spent a little time investigating this a couple of years ago. I
> would like to see Django officially bless the idea of alternative URL
> systems, and provide the "full" regex system and preferably at least one
> "simple" system - even if all that system supports is integers and slugs.
> This would allow third party authors to focus on designing their "to regex"
> translation, rather than the details of Django's resolving.
> I did some investigation into swapping at a "deeper" level, including
> allowing mixed includes from one resolver type to another. This is made
> somewhat harder by the removal of "patterns", and was much more complex.
> However it did give much more flexibility in allowing URL patterns which
> route based on other attributes than the path. I dont have any working
> code, it was very conceptual. I think we should at least consider a more
> dramatic approach in a DEP, even if it is not the intended course.
> On 15 Sep 2016 9:52 a.m., "Sjoerd Job Postmus" <sjoe...@sjec.nl
>> On Thursday, September 15, 2016 at 10:38:09 AM UTC+2, Michal Petrucha
>>> As cool as this idea sounds, I really don't think the URL dispatcher
>>> is a correct component to make database queries. FWIW, I've seen
>>> similar magic implemented in view decorators, and the thing I remember
>>> the most from this experience was that it made it a lot harder to
>>> follow what was happening where.
>>> Moreover, I can imagine this turning into a complicated mess of a
>>> syntax to allow query customizations using a weird DSL really quickly.
>>> After all, if we allow PK lookups, it's not that unreasonable to also
>>> want to be able to lookup by other keys, and it all goes downhill from
>> Agreed. It all goes downhill from there, so let's at least not do
>> database queries.
>> To me, that settles it: no typecasting.
>> 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
>> To post to this group, send email to django-d...@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.
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 email@example.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.