Simplified routing syntax #27

sjoerdjob · 2016-10-19T22:17:51Z

Mostly a rewrite of https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98 in rST.

ryanhiebert · 2016-10-19T22:20:33Z

draft/simplified-routing-syntax.rst

+
+	urlpatterns = [
+		path('/users/', views.user_list),
+		path('/users/<id>/', views.user_detail),


The previous example left off the leading slash, but this one has it. I suspect that we want the former, but which is correct.

Yes, I just copied & pasted that from the original proposal from Tom Christie, but other parts of the DEP are clear that it is about path components and not URLs, so this will have to change.

The route argument to the ``path`` function signifies a component of the full URL, and as such should (normally) not start with a ``/``. Thanks Ryan Hiebert.

wlonk · 2016-10-19T22:30:28Z

draft/simplified-routing-syntax.rst

+
+* Enforce that new style ``path()`` arguments must not start with a leading
+  ``'^'``.
+* Enfore that old style ``url()`` arguments must start with a leading ``'^'``.


Typo: "Enforce".

Thanks! I fixed it and pushed a new commit.

wlonk · 2016-10-19T22:31:46Z

I love this proposal, for the record. It obviates a tiny library I made for myself, in a great way.

Thanks Kit La Touche!

tomchristie · 2016-11-07T11:07:02Z

Okay, I think this is ready for a formal DEP #, right?
Some minor stuff around the edges to be worked out as we progress.

alexwlchan

I flagged a few minor spelling errors, but otherwise looks good! Django's URL routing is a point of personal frustration (I came from Flask to Django), so I'd be very pleased if this got fixed. 😄

alexwlchan · 2016-11-07T12:01:06Z

draft/simplified-routing-syntax.rst

+
+There are two aspects to this that we'd like to improve on:
+
+* The Regex based URL syntax is unneccessarily verbose and complex for the vast


/s/unneccessarily/unnecessarily

Thanks for the spelling reports! I've just fixed them.

alexwlchan · 2016-11-07T12:02:18Z

draft/simplified-routing-syntax.rst

+
+We might also consider including `a regex converter <http://stackoverflow.com/questions/5870188/does-flask-support-regular-expressions-in-its-url-routing>`_.
+
+Furthermore, an interface for implementating custom converters should exist. We


/s/implementating/implementing

alexwlchan · 2016-11-07T12:02:45Z

draft/simplified-routing-syntax.rst

+* The items in the ``converters`` argument would each be instances of
+  ``BaseConverter``
+
+(An alternate might be to add separate ``converter_args`` and


/s/alternate/alternative

alexwlchan · 2016-11-07T12:02:57Z

draft/simplified-routing-syntax.rst

+Preventing unintended errors
+----------------------------
+
+*The following behaviour is not neccessary, and we might not choose to add


/s/neccessary/necessary

alexwlchan · 2016-11-07T12:03:25Z

draft/simplified-routing-syntax.rst

+Implementation tasks
+====================
+
+The following independant tasks can be identified:


/s/independant/independent

sjoerdjob · 2016-11-10T08:34:24Z

@tomchristie: Now that I've fixed the spelling issues, I think it is ready for a formal DEP #.

mjtamlyn · 2016-11-10T09:50:21Z

I've had a skim through and I feel this is ready to be merged into the drafts folder. @tomchristie - you should have the commit access to do that?

tomchristie · 2016-11-10T10:52:24Z

@mjtamlyn - Nope, I don't have commit access. Yup, agree that it's ready for drafts.

mjtamlyn · 2016-11-11T09:46:49Z

Assigned number 0201 (seemed unlikely it would get done by 1.11 feature freeze in January) and I couldn't work out how to fit 1.11 into the number scheme anyway. Merged into master in 5b306de

tomchristie · 2016-11-11T09:56:00Z

Assigned number 0201

Does that have any impact, or is it just symbolic? I'd like to aim to get it in for 1.11 and can make some time to help with that if needed.

mjtamlyn · 2016-11-11T10:18:34Z

It's pretty much symbolic the number yeah. If you can get it all working and merged by the feature freeze then great, but it's still just a draft. We'll need a concrete plan and a technical board vote to get it to accepted, and then a mergable patch to get it to final.

tomchristie · 2016-11-11T10:33:37Z

The current state of the pull request is pretty far along django/django#7482

The "Parametrisable converter syntax" is the one substantial technical aspect of this that's still TODO. (Plenty to do in the documentation and a couple of more minor dev aspects to address)

Putting that aside I don't see any reason for us not to starting to addressing the potential blockers for this getting in, namely:

Do we adopt path throughout the documentation at this point or not? (We could add it as an option, but not use it as the canonical choice to start with if we wanted.)
Are we happy with from django.urls import path and from django.urls import regex_path or not? (We could stick with django.conf.urls if we wanted.)
Do we put django.conf.urls import url onto a deprecation timeline or not? (It's used in 100% of projects right now, should we could choose to extend its usage as a deprecation-free synonym of regex_path)

sjoerdjob · 2016-11-11T10:37:21Z

If it helps, I would not mind shelving the parametrisation, making it more likely that this can be completed before the deadline. (Also, I think it is a bit more controversial and a bit less specified than the rest of the proposal, to be honest).

jezdez · 2016-11-11T13:13:07Z

@tomchristie

yes, adopt it throughout the docs
django.urls is the canonical place for URL stuff, also move django.core.urlresolvers into django.urls.resolvers
yes, django.conf.urls.url needs to be deprecated as usual

mjtamlyn · 2016-11-11T13:28:37Z

Yes to docs
+1 to flattening the import paths
Probably.

I'm concerned about the lack of technical details regarding reversing of these new URLs in the DEP. I see from the PR that some of this has been solved? The approaches should be mentioned here.

I'd also like to see how the direction of any internal reworking here can be combined with Andrew's routing taking other attributes in channels and with django-hosts. I'm happy for the conclusion to be that this could be a future piece of work, but I'd like to see it discussed within the DEP.

sjoerdjob · 2016-11-11T14:11:44Z

I agree with respect to docs and the flattened import paths.

For deprecation, I think the patterns gives a good example: it was deprecated in 1.8 and removed in 1.10. I think if we can get this in before 1.11, maybe we could even remove the old import location for 2.0.

The part regarding reversing has not been mentioned in the DEP indeed, but are a solvable problem. I'll create a PR updating DEP0201 to document the changes needed the reversing (API and internals).

As for the Channels and Django-Hosts: Sounds interesting, but I think for now it needs to be "future work" as

I don't see a hook to add this and allow reversing to still work.
It's orthogonal: this is only about simplified syntax (and converting data-types). channels/hosts is about matching on different data-types.

Again, I'll see if I can reword this a bit more elegantly for in DEP0201.

tomchristie · 2016-11-11T16:38:53Z

Docs patch, in progress: django/django#7542

sjoerdjob · 2016-11-14T08:41:52Z

I created a PR with some amendments: #34

sjoerdjob added 3 commits October 19, 2016 22:16

Draft of Simplified routing syntax

684ac24

Be consistent with respect to spelling of Converter.

3094e09

Update last modified date.

9b28cf6

ryanhiebert reviewed Oct 19, 2016

View reviewed changes

Fix starting slash in example pattern.

ad08320

The route argument to the ``path`` function signifies a component of the full URL, and as such should (normally) not start with a ``/``. Thanks Ryan Hiebert.

wlonk reviewed Oct 19, 2016

View reviewed changes

Fix typo (enfore => enforce).

eba207d

Thanks Kit La Touche!

sjoerdjob mentioned this pull request Nov 5, 2016

Fixed #28593 -- Added a simplified URL routing syntax per DEP 0201. django/django#7482

Merged

alexwlchan reviewed Nov 7, 2016

View reviewed changes

sjoerdjob added 2 commits November 9, 2016 21:06

Fix spelling errors as reported by Alex Chan

f75432a

Fix another typo.

448a81b

mjtamlyn closed this Nov 11, 2016

sjoerdjob deleted the simplified-routing-syntax branch November 14, 2016 08:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplified routing syntax #27

Simplified routing syntax #27

sjoerdjob commented Oct 19, 2016

ryanhiebert Oct 19, 2016

sjoerdjob Oct 19, 2016

wlonk Oct 19, 2016

sjoerdjob Oct 20, 2016

wlonk commented Oct 19, 2016

tomchristie commented Nov 7, 2016

alexwlchan left a comment

alexwlchan Nov 7, 2016

sjoerdjob Nov 9, 2016

alexwlchan Nov 7, 2016

alexwlchan Nov 7, 2016

alexwlchan Nov 7, 2016

alexwlchan Nov 7, 2016

sjoerdjob commented Nov 10, 2016

mjtamlyn commented Nov 10, 2016

tomchristie commented Nov 10, 2016

mjtamlyn commented Nov 11, 2016

tomchristie commented Nov 11, 2016

mjtamlyn commented Nov 11, 2016 •

edited

Loading

tomchristie commented Nov 11, 2016 •

edited

Loading

sjoerdjob commented Nov 11, 2016

jezdez commented Nov 11, 2016

mjtamlyn commented Nov 11, 2016

sjoerdjob commented Nov 11, 2016

tomchristie commented Nov 11, 2016

sjoerdjob commented Nov 14, 2016


		There are two aspects to this that we'd like to improve on:

		* The Regex based URL syntax is unneccessarily verbose and complex for the vast


		We might also consider including `a regex converter <http://stackoverflow.com/questions/5870188/does-flask-support-regular-expressions-in-its-url-routing>`_.

		Furthermore, an interface for implementating custom converters should exist. We

Simplified routing syntax #27

Simplified routing syntax #27

Conversation

sjoerdjob commented Oct 19, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wlonk commented Oct 19, 2016

tomchristie commented Nov 7, 2016

alexwlchan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sjoerdjob commented Nov 10, 2016

mjtamlyn commented Nov 10, 2016

tomchristie commented Nov 10, 2016

mjtamlyn commented Nov 11, 2016

tomchristie commented Nov 11, 2016

mjtamlyn commented Nov 11, 2016 • edited Loading

tomchristie commented Nov 11, 2016 • edited Loading

sjoerdjob commented Nov 11, 2016

jezdez commented Nov 11, 2016

mjtamlyn commented Nov 11, 2016

sjoerdjob commented Nov 11, 2016

tomchristie commented Nov 11, 2016

sjoerdjob commented Nov 14, 2016

mjtamlyn commented Nov 11, 2016 •

edited

Loading

tomchristie commented Nov 11, 2016 •

edited

Loading