URL Dispatcher

[James Addison]

In the interests of keeping the excellent work done by Marten Kenbeek (knbk on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current and moving along, I've created a new branch [2] and rebased it against current master. (I am doing this because it seems like Marten is no longer able to continue working on the effort. If this should change or is incorrect, Marten, please let me/us know!)

To try and find how far along the project is, I've quickly compared the original GSOC outline/timeline [1] against my updated branch [2] to see what is done/remaining:

• section 3.1 (Design phase) I believe was done, but am unable to find anything other than a few posts on the django-developer mailing list - is there a source for this?
• section 3.2 (Namespace overhaul) hasn't been addressed that I can tell - I'd recommend dropping this as it isn't core to the effort
• Items completed in section 3.3 (Dispatcher API): 3.3.[1-4]
• Items remaining in section 3.3: (Dispatcher API): 3.3.[5-9] - some highlights:
• re-implementing some legacy functionality for backward compatibility (ie. RegexURLPattern)
• additional tests
• lots of documentation!
• additional resolvers (ie. scheme, sub-domain, etc)

Please keep in mind that I'm mostly unfamiliar with the internals of Django core elements, so I may have easily overlooked/mistook relevant information. I'd appreciate any other review/input as well. Here is the branch comparison [3] on Github.

Based on the Django 1.9 release schedule, I have doubts that this will be merged in for feature freeze, which is unfortunate. I would like to think that I am up to the task, but the URL functionality in Django is about as 'core' as it gets and I would not want to bite off more than I can chew without backup. Any thoughts on the continued viability of this effort? Is this something that someone inexperienced with Django internals should take on? If so, I'd definitely need coaching!

Lastly, I want to mention that I do have a new project in which I had been using Marten's branch (and am now using my own branch [2]), and it has been functionally solid for the scheme, (sub) domain and url resolving and reversing use cases. See the the urls.py [4] from that project to whet your appetites as to the possibilities of all this. :)

Previous discussions on the django-developers mailing list [5].

[1] https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904

[2] https://github.com/jaddison/django/tree/gsoc2015_url_dispatcher

[3] https://github.com/django/django/compare/master...jaddison:gsoc2015_url_dispatcher

[4] https://gist.github.com/jaddison/18dea1bf93767f326aa5

[5] https://groups.google.com/forum/#!searchin/django-developers/marten/django-developers/IoivPLHJ_nw and https://groups.google.com/forum/#!searchin/django-developers/marten/django-developers/WQoJN_MGTOg (most recent)

Cheers,

James Addison

[Tim Graham]

Thanks for taking this on, James. I do think it would be best to defer this to Django 1.10 rather than try to rush it into Django 1.9 at this point. Also, there are several URL related deprecations scheduled to complete in 1.10 which should simplify things (I've started on those removals here: https://github.com/django/django/pull/5143). Absent another interested person, I should be able to mentor you on this during the Django 1.10 release cycle (which can start once we cut the stable/1.9.x branch after 1.9 alpha around September 21). In the meantime, if you want take a look for some simpler tickets to tackle to get a feel for our contribution process, I think that would be helpful.

[Marten Kenbeek]

Hi James,

Thanks for keeping this alive while I had some personal issues to sort out. I'll be working on this again, though I can use all the help I can get. 

As for the work that still needs to be done:

• 3.1 is done, mostly as a proof-of-concept that can be found at https://github.com/knbk/django/tree/url_dispatcher
  
• 3.2 is done. I've worked on this in separate PR's, which have all been merged by now. 
• 3.3: 
• Legacy functionality has been implemented, namely through the RegexPattern, LocalizedRegexPattern and LocalePrefix constraints.
• I've kept a lot of functional tests, and I believe the unit tests have decent coverage. It would be good to have more tests, but I don't think it's a necessity. 
• Yes, pretty much all the documentation must still be written. 
• These could be implemented pretty straight-forward in separate patches after the main project has been merged. 

The resolver is not quite as fast as I'd hoped, especially `reverse()`. There are some trade-offs we can make, but we'll have to decide which are worth it. 

I think that is the main problem we need to tackle before we push for a merge. 

Marten

Op dinsdag 25 augustus 2015 20:57:14 UTC+2 schreef Tim Graham:

[James Addison]

Marten, good to have you back in the fold. I'll leave the effort in your hands (phew!) - as before, let me know if I can help in any way. I'm fairly new to Django internals, so don't expect much!

I can test, however, and help with docs somewhat (based on limited knowledge).

Cheers,
James

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/9AqFxIIW2Mk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/4d4f287a-007a-42ba-a7ff-ab37560e262d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.