DEP pre-proposal for a simpler URLs syntax.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

DEP pre-proposal for a simpler URLs syntax.

tom christie
Hi folks,

I wanted to push forward the consideration of introducing a simpler URLs syntax, plus support for URL parameter type conversion.

A pre-proposal is available here: https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

At this point I'm seeking feedback, before hopefully iterating on the proposal, and making a formal submission.

I'm not making any assumptions right now about where this might get too, or who'd be involved if it does make it to the DEP stage, and would very much welcome outside involvement. I'm also aware that while there's been some positive reception, it's not yet clear if we'll reach a consensus on inclusion in core.

Personally I'm very firmly +1 on this, as I feel that the existing syntax is a rather glaring and unnecessary pain point.

Thanks to everyone who's started to kick this off, in particular Emil Stenström for raising the original thread, and Sjoerd Job Postmus for their work on the Django Simple URL package.

  - 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1450171a-be2b-41e8-b221-91bfe656d039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Sjoerd Job Postmus
Hi Tom,

Nicely written DEP.

I have some ideas/suggestions:

- There's text that elaborates on how to detect which one of the two options is implied. I'd recommend making that a section in and of itself.
- The DEP states that the new routing will be implemented in terms of the existing regex based system. Could you add a note here stating that that's merely an implementation detail?

Kind regards,
Sjoerd Job

On Monday, October 3, 2016 at 12:24:04 PM UTC+2, Tom Christie wrote:
Hi folks,

I wanted to push forward the consideration of introducing a simpler URLs syntax, plus support for URL parameter type conversion.

A pre-proposal is available here: <a href="https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Ftomchristie%2Fcb388f0f6a0dec931c611775f32c5f98\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxPcFiuC3Y5Js-3cNLkNzcf7nrDQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Ftomchristie%2Fcb388f0f6a0dec931c611775f32c5f98\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxPcFiuC3Y5Js-3cNLkNzcf7nrDQ&#39;;return true;">https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

At this point I'm seeking feedback, before hopefully iterating on the proposal, and making a formal submission.

I'm not making any assumptions right now about where this might get too, or who'd be involved if it does make it to the DEP stage, and would very much welcome outside involvement. I'm also aware that while there's been some positive reception, it's not yet clear if we'll reach a consensus on inclusion in core.

Personally I'm very firmly +1 on this, as I feel that the existing syntax is a rather glaring and unnecessary pain point.

Thanks to everyone who's started to kick this off, in particular Emil Stenström for raising the original thread, and Sjoerd Job Postmus for their work on the <a href="https://github.com/sjoerdjob/django-simple-url" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fsjoerdjob%2Fdjango-simple-url\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGQ9J_W-u4cBKGKbmC3MdhA0_uc0A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fsjoerdjob%2Fdjango-simple-url\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGQ9J_W-u4cBKGKbmC3MdhA0_uc0A&#39;;return true;">Django Simple URL package.

  - 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1d4e1382-e91b-469d-9f7b-dbf84a94e6b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

tom christie
> There's text that elaborates on how to detect which one of the two options is implied. I'd recommend making that a section in and of itself.

Probably a good plan, yup. I was somewhat writing that section as I thought, so it comes out a bit jumbled. I'm more confident in retrospect that regex vs typed detection is a reasonable approach. I can't see any obvious problems there that I'm missing. I'll take another pass at that in due course.

> The DEP states that the new routing will be implemented in terms of the existing regex based system. Could you add a note here stating that that's merely an implementation detail?

Yup - I've done a bit of re-wording in order to try to clear that up.

Thanks!

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ea247b0b-bc49-4de4-86d1-9cd765c0f42b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Jacob Kaplan-Moss-2
In reply to this post by tom christie
Hi Tom -

Thanks for putting this together! Overall, +1 from me as well: I've taught Django to a bunch of beginners, and URLs are one of the major pain points. I'd love to make them easier, and your proposal looks pretty dang great.

Some specific feedback:

1. I'm not too thrilled on the "is this a regex or not?" auto-detection: my experience has been that every time we try to be clever like that, we end up regretting it down the line. "Explicit is better than implicit", and all that. It's more awkward, but I'd prefer different calls/constructors for URLs. I think this also lets us set up a better upgrade/transition path. My suggestion is that we move towards `url()` giving "new style" patterns, and have another helper ("url_regex"? "urlr"?) that provides regex resolving. We could also take this opportunity to simplify import paths, so:

- `from django.urls import url` <--- new-style resolver
- `from django.urls import url_regex` <--- old-style resolver
- `from django.conf.urls import url` <--- old-style resolver, with PendingDeprecation/DeprecationWarning, then deleted - as per normal upgrade path.

2. Huge +1 on copying Flask's converters and API. Flask nailed the routing syntax, no need to reinvent the wheel!

3. Documentation: I suggest introducing the new syntax immediately in all the documentation. It's better for like 90% of the cases.

Thanks again, I'm stoked to see some motion here.

Jacob

On Mon, Oct 3, 2016 at 3:24 AM, Tom Christie <[hidden email]> wrote:
Hi folks,

I wanted to push forward the consideration of introducing a simpler URLs syntax, plus support for URL parameter type conversion.

A pre-proposal is available here: https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

At this point I'm seeking feedback, before hopefully iterating on the proposal, and making a formal submission.

I'm not making any assumptions right now about where this might get too, or who'd be involved if it does make it to the DEP stage, and would very much welcome outside involvement. I'm also aware that while there's been some positive reception, it's not yet clear if we'll reach a consensus on inclusion in core.

Personally I'm very firmly +1 on this, as I feel that the existing syntax is a rather glaring and unnecessary pain point.

Thanks to everyone who's started to kick this off, in particular Emil Stenström for raising the original thread, and Sjoerd Job Postmus for their work on the Django Simple URL package.

  - 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1450171a-be2b-41e8-b221-91bfe656d039%40googlegroups.com.
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAK8PqJEbne2fp9X3Q1Dgr7OG3Ns54A1gqdndwCD5FXNT8j%3DXTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

tom christie
> My suggestion is that we move towards `url()` giving "new style" patterns

Agreed. I couldn't see a nice way around to do that, but moving the import to `from django.urls import url` sidesteps the issue nicely.
Sounds good to me.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5384cbd3-5873-4532-9a0f-9963d20d13dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Aymeric Augustin
In reply to this post by Jacob Kaplan-Moss-2
+1 Tom’s proposal and Jacob’s comments.

-- 
Aymeric.

On 03 Oct 2016, at 16:39, Jacob Kaplan-Moss <[hidden email]> wrote:

Hi Tom -

Thanks for putting this together! Overall, +1 from me as well: I've taught Django to a bunch of beginners, and URLs are one of the major pain points. I'd love to make them easier, and your proposal looks pretty dang great.

Some specific feedback:

1. I'm not too thrilled on the "is this a regex or not?" auto-detection: my experience has been that every time we try to be clever like that, we end up regretting it down the line. "Explicit is better than implicit", and all that. It's more awkward, but I'd prefer different calls/constructors for URLs. I think this also lets us set up a better upgrade/transition path. My suggestion is that we move towards `url()` giving "new style" patterns, and have another helper ("url_regex"? "urlr"?) that provides regex resolving. We could also take this opportunity to simplify import paths, so:

- `from django.urls import url` <--- new-style resolver
- `from django.urls import url_regex` <--- old-style resolver
- `from django.conf.urls import url` <--- old-style resolver, with PendingDeprecation/DeprecationWarning, then deleted - as per normal upgrade path.

2. Huge +1 on copying Flask's converters and API. Flask nailed the routing syntax, no need to reinvent the wheel!

3. Documentation: I suggest introducing the new syntax immediately in all the documentation. It's better for like 90% of the cases.

Thanks again, I'm stoked to see some motion here.

Jacob

On Mon, Oct 3, 2016 at 3:24 AM, Tom Christie <[hidden email]> wrote:
Hi folks,

I wanted to push forward the consideration of introducing a simpler URLs syntax, plus support for URL parameter type conversion.

A pre-proposal is available here: https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

At this point I'm seeking feedback, before hopefully iterating on the proposal, and making a formal submission.

I'm not making any assumptions right now about where this might get too, or who'd be involved if it does make it to the DEP stage, and would very much welcome outside involvement. I'm also aware that while there's been some positive reception, it's not yet clear if we'll reach a consensus on inclusion in core.

Personally I'm very firmly +1 on this, as I feel that the existing syntax is a rather glaring and unnecessary pain point.

Thanks to everyone who's started to kick this off, in particular Emil Stenström for raising the original thread, and Sjoerd Job Postmus for their work on the Django Simple URL package.

  - 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1450171a-be2b-41e8-b221-91bfe656d039%40googlegroups.com.
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAK8PqJEbne2fp9X3Q1Dgr7OG3Ns54A1gqdndwCD5FXNT8j%3DXTw%40mail.gmail.com.
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/D5256C17-164F-4123-B07C-7A62100AE7F1%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Ryan Hiebert-2
Loving this work! There's one thing that Flask's routing syntax does that strikes me as backward, and it may be a good idea to consider reversing it: the converter indication.

I suggest that rather than it being `<converter:name>` it should be `<name:converter>`, because the converter is very similar to a type, and we have the precedence of Python's typing syntax of `name: type`. It meets my sensibilities to follow Python's example.

Of course, we've also got the example from Flask to contend with, so it's a value judgement.


On Oct 3, 2016, at 10:55 AM, Aymeric Augustin <[hidden email]> wrote:

+1 Tom’s proposal and Jacob’s comments.

-- 
Aymeric.

On 03 Oct 2016, at 16:39, Jacob Kaplan-Moss <[hidden email]> wrote:

Hi Tom -

Thanks for putting this together! Overall, +1 from me as well: I've taught Django to a bunch of beginners, and URLs are one of the major pain points. I'd love to make them easier, and your proposal looks pretty dang great.

Some specific feedback:

1. I'm not too thrilled on the "is this a regex or not?" auto-detection: my experience has been that every time we try to be clever like that, we end up regretting it down the line. "Explicit is better than implicit", and all that. It's more awkward, but I'd prefer different calls/constructors for URLs. I think this also lets us set up a better upgrade/transition path. My suggestion is that we move towards `url()` giving "new style" patterns, and have another helper ("url_regex"? "urlr"?) that provides regex resolving. We could also take this opportunity to simplify import paths, so:

- `from django.urls import url` <--- new-style resolver
- `from django.urls import url_regex` <--- old-style resolver
- `from django.conf.urls import url` <--- old-style resolver, with PendingDeprecation/DeprecationWarning, then deleted - as per normal upgrade path.

2. Huge +1 on copying Flask's converters and API. Flask nailed the routing syntax, no need to reinvent the wheel!

3. Documentation: I suggest introducing the new syntax immediately in all the documentation. It's better for like 90% of the cases.

Thanks again, I'm stoked to see some motion here.

Jacob

On Mon, Oct 3, 2016 at 3:24 AM, Tom Christie <[hidden email]> wrote:
Hi folks,

I wanted to push forward the consideration of introducing a simpler URLs syntax, plus support for URL parameter type conversion.

A pre-proposal is available here: https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

At this point I'm seeking feedback, before hopefully iterating on the proposal, and making a formal submission.

I'm not making any assumptions right now about where this might get too, or who'd be involved if it does make it to the DEP stage, and would very much welcome outside involvement. I'm also aware that while there's been some positive reception, it's not yet clear if we'll reach a consensus on inclusion in core.

Personally I'm very firmly +1 on this, as I feel that the existing syntax is a rather glaring and unnecessary pain point.

Thanks to everyone who's started to kick this off, in particular Emil Stenström for raising the original thread, and Sjoerd Job Postmus for their work on the Django Simple URL package.

  - 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1450171a-be2b-41e8-b221-91bfe656d039%40googlegroups.com.
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAK8PqJEbne2fp9X3Q1Dgr7OG3Ns54A1gqdndwCD5FXNT8j%3DXTw%40mail.gmail.com.
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/D5256C17-164F-4123-B07C-7A62100AE7F1%40polytechnique.org.
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/A81B50C3-D41B-498E-A9C5-DF38FC5824A1%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

tom christie
Okay then, I've made some updates:

* Updated the import design, in line with Jacob's suggestion.
* Brief note on URL conventions, and the leading '/'.
* Section on guarding against errors between `from django.conf.urls import url` and `from django.urls import url`.
* Brief note on the internal RegexURLPattern API.
* Breakout of required implementation tasks.

 Also, wrt Ryan's suggestion of reversing the ordering of name and type: I've some sympathy towards it, but I believe that presenting a consistent API between both Flask and Django is a more important factor.

Cheers all,

  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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Markus Holtermann
Thanks for the draft, Tom. I'm a bit concerned that the different
`url*()` functions you can import will become confusing. Can we have
`regex_url()` (with chim for `url()`) -- as proposed -- and
`simple_url()` instead?

/Markus

On Mon, Oct 03, 2016 at 02:34:58PM -0700, Tom Christie wrote:

>Okay then, I've made some updates:
>
>* Updated the import design, in line with Jacob's suggestion.
>* Brief note on URL conventions, and the leading '/'.
>* Section on guarding against errors between `from django.conf.urls import
>url` and `from django.urls import url`.
>* Brief note on the internal RegexURLPattern API.
>* Breakout of required implementation tasks.
>
> Also, wrt Ryan's suggestion of reversing the ordering of name and type:
>I've some sympathy towards it, but I believe that presenting a consistent
>API between both Flask and Django is a more important factor.
>
>Cheers all,
>
>  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 [hidden email].
>To post to this group, send email to [hidden email].
>Visit this group at https://groups.google.com/group/django-developers.
>To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%40googlegroups.com.
>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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20161003221128.GB23889%40pyler.local.
For more options, visit https://groups.google.com/d/optout.

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Aymeric Augustin
Hello,

I agree that different names would be better. I wouldn’t use the word “simple” since many “simple” things grow and become less simple in the long run. SOAP stands for Simple Object Access Protocol… For this reason url() and regex_url() have my preference.

I’m in favor of the <name:type> order because I believe that “consistency with Python” is a stronger argument than “consistency with Flask”, but I have to admit that I never made significant use of Flask.

Best regards,

--
Aymeric.

> On 04 Oct 2016, at 00:11, Markus Holtermann <[hidden email]> wrote:
>
> Thanks for the draft, Tom. I'm a bit concerned that the different
> `url*()` functions you can import will become confusing. Can we have
> `regex_url()` (with chim for `url()`) -- as proposed -- and
> `simple_url()` instead?
>
> /Markus
>
> On Mon, Oct 03, 2016 at 02:34:58PM -0700, Tom Christie wrote:
>> Okay then, I've made some updates:
>>
>> * Updated the import design, in line with Jacob's suggestion.
>> * Brief note on URL conventions, and the leading '/'.
>> * Section on guarding against errors between `from django.conf.urls import
>> url` and `from django.urls import url`.
>> * Brief note on the internal RegexURLPattern API.
>> * Breakout of required implementation tasks.
>>
>> Also, wrt Ryan's suggestion of reversing the ordering of name and type:
>> I've some sympathy towards it, but I believe that presenting a consistent
>> API between both Flask and Django is a more important factor.
>>
>> Cheers all,
>>
>> 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 [hidden email].
>> To post to this group, send email to [hidden email].
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%40googlegroups.com.
>> 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 [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20161003221128.GB23889%40pyler.local.
> 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/DF8D81E2-7370-494C-90E4-E28E0A9B3897%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Markus Holtermann
Hi y'all,

On Tue, Oct 04, 2016 at 08:15:45AM +0200, Aymeric Augustin wrote:
>I agree that different names would be better. I wouldn’t use the word
>“simple” since many “simple” things grow and become less simple in the
>long run. SOAP stands for Simple Object Access Protocol… For this
>reason url() and regex_url() have my preference.

By all means, if we can find another prefix that's not "simple" I'm all
in. I believe it will be too confusing for people who have used Django
for years to get used to the rename of regex_url to url, especially if
you can import two `url()` functions from different places where one is
a chim for the old regex-y function and one is the new flask-y function.

>I’m in favor of the <name:type> order because I believe that
>“consistency with Python” is a stronger argument than “consistency with
>Flask”, but I have to admit that I never made significant use of Flask.

I somewhat disagree. I think we shouldn't make switching between Flask
and Django more annoying than necessary in that we swap the ordering in
which the parameter types are defined in URLs.

The Python syntax for type hints feels different for me by the very
nature of "being Python code" whereas the URL definitions are "just
strings"

/Markus

>--
>Aymeric.
>
>> On 04 Oct 2016, at 00:11, Markus Holtermann <[hidden email]> wrote:
>>
>> Thanks for the draft, Tom. I'm a bit concerned that the different
>> `url*()` functions you can import will become confusing. Can we have
>> `regex_url()` (with chim for `url()`) -- as proposed -- and
>> `simple_url()` instead?
>>
>> /Markus
>>
>> On Mon, Oct 03, 2016 at 02:34:58PM -0700, Tom Christie wrote:
>>> Okay then, I've made some updates:
>>>
>>> * Updated the import design, in line with Jacob's suggestion.
>>> * Brief note on URL conventions, and the leading '/'.
>>> * Section on guarding against errors between `from django.conf.urls import
>>> url` and `from django.urls import url`.
>>> * Brief note on the internal RegexURLPattern API.
>>> * Breakout of required implementation tasks.
>>>
>>> Also, wrt Ryan's suggestion of reversing the ordering of name and type:
>>> I've some sympathy towards it, but I believe that presenting a consistent
>>> API between both Flask and Django is a more important factor.
>>>
>>> Cheers all,
>>>
>>> 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 [hidden email].
>>> To post to this group, send email to [hidden email].
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%40googlegroups.com.
>>> 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 [hidden email].
>> To post to this group, send email to [hidden email].
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20161003221128.GB23889%40pyler.local.
>> 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 [hidden email].
>To post to this group, send email to [hidden email].
>Visit this group at https://groups.google.com/group/django-developers.
>To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/DF8D81E2-7370-494C-90E4-E28E0A9B3897%40polytechnique.org.
>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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20161004075413.GD23889%40pyler.local.
For more options, visit https://groups.google.com/d/optout.

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Raphael Michel
In reply to this post by Markus Holtermann
Hi,

Am Tue, 4 Oct 2016 00:11:28 +0200
schrieb Markus Holtermann <[hidden email]>:
> Thanks for the draft, Tom. I'm a bit concerned that the different
> `url*()` functions you can import will become confusing. Can we have
> `regex_url()` (with chim for `url()`) -- as proposed -- and
> `simple_url()` instead?

yes, we should at all cost avoid two functions named url() that behave
differently. The proposed import paths look to similar to be easily
differentiated on first sight and I normally just type `url` and hit
Alt+Enter to have my IDE do an automatic lookup. I believe this would
be a big burden for people used to the old syntax AND newcomers
(because of the autoimport that is not helping).

Raphael

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20161004100240.3bfb0bb9%40arlen.
For more options, visit https://groups.google.com/d/optout.

attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

tom christie
Some possibilities:

1. Use a different name for the new function.

    path('/users/<int:pk>/')

Actually `path` is pretty valid as a name there - that's *exactly* what it represents - the path portion of the URL.
Alternately `route`?

2. Keep `url` for both styles, but with a really simple determination between regexs/typed urls.

    The pattern *must* start with either `^` or `/`.  (Include a `regex_url` and `typed_url` for the explicit cases)

3. As per (2) but additionally have the usage of regexs in `url(...)` be placed on the deprecation path.

I think (1) is probably my favorite choice of those, but I'm open to discussion.
That'd give us `from django.conf import path`, and `from django.conf import regex_path`. The existing `from django.conf.urls import url` would keep the existing behavior but move towards deprecation.

I'm very strongly in favor of keeping Flask's style for "<type:name>".
Considering the wider ecosystem, the choice between having Python's two biggest web frameworks share the same routing syntax vs. having them share subtly different syntaxes is pretty clear.
I think that's a far bigger concern that if the routing syntax echos Python's type hinting syntax or not.

To me, the alternative reads like this:

A: "Hey folks! Django's got a new routing sytnax!"
B: "Great what's it like?"
A: "Exactly the same as Flask. Oh, but we've reversed two of the arguments around."
B: "Uh, WTF?"

Cheers for the input everyone,

  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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7550dd77-ef22-4b92-b42e-aad6116ffc84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

DoctorMO
In reply to this post by tom christie
This looks like a useful addition.

I'd also like to chip in with a DRY pattern I've been using in all my projects which might be worth considering.

To take your example:

def url_tree(regex, *urls):
    return url(regex, include(patterns('', *urls)))

urlpatterns = [
 url_tree('articles/',
  url('2003/', views.special_case_2003),
  url_tree('<int:year>/',
  url('', views.year_archive),
url_tree('<int:month>/',
  url('', views.month_archive),
url('<int:day>/', views.article_detail),
),
  ),
  ),
 ]

So long as the proposal doesn't make the above url_tree pattern impossible (or harder to do) then I think it's a positive addition. (I have projects which have very interesting urls patterns)

Best Regards, Martin Owens
Inkscape Website, django 1.8

On Monday, October 3, 2016 at 6:24:04 AM UTC-4, Tom Christie wrote:
Hi folks,

I wanted to push forward the consideration of introducing a simpler URLs syntax, plus support for URL parameter type conversion.

A pre-proposal is available here: <a href="https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Ftomchristie%2Fcb388f0f6a0dec931c611775f32c5f98\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxPcFiuC3Y5Js-3cNLkNzcf7nrDQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Ftomchristie%2Fcb388f0f6a0dec931c611775f32c5f98\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxPcFiuC3Y5Js-3cNLkNzcf7nrDQ&#39;;return true;">https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

At this point I'm seeking feedback, before hopefully iterating on the proposal, and making a formal submission.

I'm not making any assumptions right now about where this might get too, or who'd be involved if it does make it to the DEP stage, and would very much welcome outside involvement. I'm also aware that while there's been some positive reception, it's not yet clear if we'll reach a consensus on inclusion in core.

Personally I'm very firmly +1 on this, as I feel that the existing syntax is a rather glaring and unnecessary pain point.

Thanks to everyone who's started to kick this off, in particular Emil Stenström for raising the original thread, and Sjoerd Job Postmus for their work on the <a href="https://github.com/sjoerdjob/django-simple-url" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fsjoerdjob%2Fdjango-simple-url\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGQ9J_W-u4cBKGKbmC3MdhA0_uc0A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fsjoerdjob%2Fdjango-simple-url\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGQ9J_W-u4cBKGKbmC3MdhA0_uc0A&#39;;return true;">Django Simple URL package.

  - 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ab9eb20f-3d91-4a6f-9905-280909ba0abd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Markus Holtermann
In reply to this post by tom christie
Thanks for your update, Tom!

1. I think `route` is used in Django Channels (haven't looked it up. Not
a real issue but something to think about). I'd prefer `path` instead.

2. Too much magic for my taste. I like the explicit name `typed_url`
though (if we stick with `url` as opposed to `path` as per 1.). So
either `regex_url` and `typed_url` or `regex_path` and `typed_path`.
Either one with a import chim for `django.conf.urls.url` to point to
`regex_url` or `regex_path`.

3. Consider me -0 to -1 on deprecating `url()`. If we "rename" `url` to
`path` I'd rather see the docs updated and have a chim around for _a
while_. It's unnecessary work for every user to fix this in _every_
Django project.

/Markus

On Tue, Oct 04, 2016 at 02:17:00AM -0700, Tom Christie wrote:

>Some possibilities:
>
>1. Use a different name for the new function.
>
>    path('/users/<int:pk>/')
>
>Actually `path` is pretty valid as a name there - that's *exactly* what it
>represents - the path portion of the URL.
>Alternately `route`?
>
>2. Keep `url` for both styles, but with a really simple determination
>between regexs/typed urls.
>
>    The pattern *must* start with either `^` or `/`.  (Include a
>`regex_url` and `typed_url` for the explicit cases)
>
>3. As per (2) but additionally have the usage of regexs in `url(...)` be
>placed on the deprecation path.
>
>I think (1) is probably my favorite choice of those, but I'm open to
>discussion.
>That'd give us `from django.conf import path`, and `from django.conf import
>regex_path`. The existing `from django.conf.urls import url` would keep the
>existing behavior but move towards deprecation.
>
>I'm very strongly in favor of keeping Flask's style for "<type:name>".
>Considering the wider ecosystem, the choice between having Python's two
>biggest web frameworks share the same routing syntax vs. having them share
>subtly different syntaxes is pretty clear.
>I think that's a far bigger concern that if the routing syntax echos
>Python's type hinting syntax or not.
>
>To me, the alternative reads like this:
>
>A: "Hey folks! Django's got a new routing sytnax!"
>B: "Great what's it like?"
>A: "Exactly the same as Flask. Oh, but we've reversed two of the arguments
>around."
>B: "Uh, WTF?"
>
>Cheers for the input everyone,
>
>  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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20161004092630.GC2270%40inel.local.
For more options, visit https://groups.google.com/d/optout.

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

ludovic coues
In my opinion, there is too much question for this DEP.
Here is a quick timeline.
September 12, Emil Stenström rise a valid criticism, using regex for
url routing is a bit too much in 99% of the case. It suggest a syntax
similar to the ruby on rails routing syntax.
September 13, someone mention surlex, something that have existed for years.
September 14, we have a new third party module using the proposed syntax.
September 19, the syntax move to the one used by flask.
October 3, we are joyfully trying to enshrine the new syntax without
technical discussion but a lot of bike shedding.

Damn, half the post here are about the order of the the group name and
the format name. Should we use year:Y or Y:year.
But nobody try to answer question like these:

Is it too early ?

What are the merit of the new URL Convention ?
 * Why do we suddenly start with slash while the regex url end with a slash ?
 * Are we following the non-existent flask convention ? Which sometime
end with a slash, sometimes not ?
 * Are we following the ruby on rail convention ?
 * The proposed convention would make the default admin url "/admin//".

Why the "preventing unintented error" ?
 * Why the shim is trying to be smart and use the typed url ?
 * Why introducing a new function named url if we believe it will be a
cause of error ?

Why do we keep the old routing system ?
 * How old is this code ?
 * Do we plan to keep it forever ?
 * Do we plan to make it harder to change it ?
 * Do we want to prevent third party module providing alternative
routing system ?

The DEP mention that the use of regex is an implementation detail.
Django come with a full test suite. It should be easy to see that an
alternative routing system is compatible with older code. Everybody
seems to be so eager to get ride of regex that they don't care how
that happen under the hood.

Are you seriously suggesting to implement the new URL as a subclass of
the old one ? If that's the case, I have a better DEP for you.
Introduce a dependency on django-simple-url. Tada, no need to alter
the django core source code. That's what the Internal RegexURLPattern
API paragraph feel like. The whole DEP feel like that.

Sorry if I sound a bit rude. I would like as much as anybody a better
way to write url than regex. But I feel like the process is rushed.

And I would really like a way to replace the whole routing component,
like we can replace the whole template component. So we can try
alternative without patching django.

2016-10-04 11:26 GMT+02:00 Markus Holtermann <[hidden email]>:

> Thanks for your update, Tom!
>
> 1. I think `route` is used in Django Channels (haven't looked it up. Not
> a real issue but something to think about). I'd prefer `path` instead.
>
> 2. Too much magic for my taste. I like the explicit name `typed_url`
> though (if we stick with `url` as opposed to `path` as per 1.). So
> either `regex_url` and `typed_url` or `regex_path` and `typed_path`.
> Either one with a import chim for `django.conf.urls.url` to point to
> `regex_url` or `regex_path`.
>
> 3. Consider me -0 to -1 on deprecating `url()`. If we "rename" `url` to
> `path` I'd rather see the docs updated and have a chim around for _a
> while_. It's unnecessary work for every user to fix this in _every_
> Django project.
>
> /Markus
>
>
> On Tue, Oct 04, 2016 at 02:17:00AM -0700, Tom Christie wrote:
>>
>> Some possibilities:
>>
>> 1. Use a different name for the new function.
>>
>>    path('/users/<int:pk>/')
>>
>> Actually `path` is pretty valid as a name there - that's *exactly* what it
>> represents - the path portion of the URL.
>> Alternately `route`?
>>
>> 2. Keep `url` for both styles, but with a really simple determination
>> between regexs/typed urls.
>>
>>    The pattern *must* start with either `^` or `/`.  (Include a
>> `regex_url` and `typed_url` for the explicit cases)
>>
>> 3. As per (2) but additionally have the usage of regexs in `url(...)` be
>> placed on the deprecation path.
>>
>> I think (1) is probably my favorite choice of those, but I'm open to
>> discussion.
>> That'd give us `from django.conf import path`, and `from django.conf
>> import
>> regex_path`. The existing `from django.conf.urls import url` would keep
>> the
>> existing behavior but move towards deprecation.
>>
>> I'm very strongly in favor of keeping Flask's style for "<type:name>".
>> Considering the wider ecosystem, the choice between having Python's two
>> biggest web frameworks share the same routing syntax vs. having them share
>> subtly different syntaxes is pretty clear.
>> I think that's a far bigger concern that if the routing syntax echos
>> Python's type hinting syntax or not.
>>
>> To me, the alternative reads like this:
>>
>> A: "Hey folks! Django's got a new routing sytnax!"
>> B: "Great what's it like?"
>> A: "Exactly the same as Flask. Oh, but we've reversed two of the arguments
>> around."
>> B: "Uh, WTF?"
>>
>> Cheers for the input everyone,
>>
>>  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 [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20161004092630.GC2270%40inel.local.
>
> For more options, visit https://groups.google.com/d/optout.



--

Cordialement, Coues Ludovic
+336 148 743 42

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEuG%2BTZg77JOdYSTuik91V4c2F9YeCWzRYSPgjwJSFQNGFw03w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Aymeric Augustin
Hello Ludovic,


On 04 Oct 2016, at 14:25, ludovic coues <[hidden email]> wrote:

> I have a better DEP for you.
> Introduce a dependency on django-simple-url.

I don’t think we want to depend on a third party package for something
as fundamental as URL dispatching. We can take good ideas and, if
the license allows it, good code from there, though.

> I would like as much as anybody a better
> way to write url than regex. But I feel like the process is rushed.

Major changes to Django are often driven by flares of excitement. I’m
sorry if that makes you uncomfortable. Usually the excitement fades
quickly and then the more boring work on the DEP starts.


Moving on to your actual questions...

> What are the merit of the new URL Convention ?

The starting slash and trailing slash are separate questions; let’s not mix them.

> * Why do we suddenly start with slash while the regex url end with a slash ?

Historically Django doesn’t include the starting slash because it’s always there,
so there’s no need to specify it every time. However everyone else writes URLs
/foo/bar/ rather than foo/bar/.

Reversing the historical decision would remove a pitfall. I think it’s worth doing it
and I also thing it’s worth explaining why in the DEP.

> * Are we following the non-existent flask convention ? Which sometime
> end with a slash, sometimes not ?
> * Are we following the ruby on rail convention ?

I assume you’re talking about the trailing slash, but if you want to have a
discussion, you’ll have to ask your question more constructively.

> * The proposed convention would make the default admin url "/admin//“.

You’re allowed to think that you’re talking to complete morons but I would
appreciate if you didn’t make it that obvious.


> Why the "preventing unintented error” ?

The DEP needs to discuss the developer experience during and after the
change.

> * Why the shim is trying to be smart and use the typed url ?

I expect further discussion on this topic. Constructive arguments welcome.

> * Why introducing a new function named url if we believe it will be a
> cause of error ?

This part of the DEP is being debated right now.


> Why do we keep the old routing system ?
> * How old is this code ?

Mostly pre-1.0, as far as I know, but that doesn’t mean much. It’s pretty good.

> * Do we plan to keep it forever ?

I didn’t see a proposal to deprecate it in the DEP, all the more since the plan
is to build the simplified system upon the current system.

> * Do we plan to make it harder to change it ?

I’m not sure why you’re saying that nor what kind of answer you expect.

> * Do we want to prevent third party module providing alternative
> routing system ?

Look at Marteen Kenbeek’s GSoC for the general direction we’re taking
and please ask the question in a less obviously biased way.


Thanks,

--
Aymeric.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/C79B391D-DC6D-4127-BC90-C2E32DE0937B%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

ludovic coues
Sorry about the way the question are formulated. Writing a rambling
post under emotion was pretty stupid of me.

About the url convention, the DEP take a pretty strong stance,
suggesting to raise an exception if the user don't use a convention
which is different from the one in place. I don't recognize the
proposed convention at all. It's not Django, it's not Ruby on Rails
and flask don't seems to have a convention on the ending slash, using
both with and without in the documentation on routing.

The only technical reason I see for enforcing the starting slash is
the smart shim, which is the main source of unintended error.


The question about the old routing system is about the plan to build
on top the old one. I'm not saying the old one is bad. But if we start
to build upon it, it will be harder to replace it. It might be more
interesting to refactor the routing system, so the new one could be
build next to the old one, rather than on top.

This might open the way for third party module providing new way to
route request in django.

2016-10-04 14:55 GMT+02:00 Aymeric Augustin
<[hidden email]>:

> Hello Ludovic,
>
>
> On 04 Oct 2016, at 14:25, ludovic coues <[hidden email]> wrote:
>
>> I have a better DEP for you.
>> Introduce a dependency on django-simple-url.
>
> I don’t think we want to depend on a third party package for something
> as fundamental as URL dispatching. We can take good ideas and, if
> the license allows it, good code from there, though.
>
>> I would like as much as anybody a better
>> way to write url than regex. But I feel like the process is rushed.
>
> Major changes to Django are often driven by flares of excitement. I’m
> sorry if that makes you uncomfortable. Usually the excitement fades
> quickly and then the more boring work on the DEP starts.
>
>
> Moving on to your actual questions...
>
>> What are the merit of the new URL Convention ?
>
> The starting slash and trailing slash are separate questions; let’s not mix them.
>
>> * Why do we suddenly start with slash while the regex url end with a slash ?
>
> Historically Django doesn’t include the starting slash because it’s always there,
> so there’s no need to specify it every time. However everyone else writes URLs
> /foo/bar/ rather than foo/bar/.
>
> Reversing the historical decision would remove a pitfall. I think it’s worth doing it
> and I also thing it’s worth explaining why in the DEP.
>
>> * Are we following the non-existent flask convention ? Which sometime
>> end with a slash, sometimes not ?
>> * Are we following the ruby on rail convention ?
>
> I assume you’re talking about the trailing slash, but if you want to have a
> discussion, you’ll have to ask your question more constructively.
>
>> * The proposed convention would make the default admin url "/admin//“.
>
> You’re allowed to think that you’re talking to complete morons but I would
> appreciate if you didn’t make it that obvious.
>
>
>> Why the "preventing unintented error” ?
>
> The DEP needs to discuss the developer experience during and after the
> change.
>
>> * Why the shim is trying to be smart and use the typed url ?
>
> I expect further discussion on this topic. Constructive arguments welcome.
>
>> * Why introducing a new function named url if we believe it will be a
>> cause of error ?
>
> This part of the DEP is being debated right now.
>
>
>> Why do we keep the old routing system ?
>> * How old is this code ?
>
> Mostly pre-1.0, as far as I know, but that doesn’t mean much. It’s pretty good.
>
>> * Do we plan to keep it forever ?
>
> I didn’t see a proposal to deprecate it in the DEP, all the more since the plan
> is to build the simplified system upon the current system.
>
>> * Do we plan to make it harder to change it ?
>
> I’m not sure why you’re saying that nor what kind of answer you expect.
>
>> * Do we want to prevent third party module providing alternative
>> routing system ?
>
> Look at Marteen Kenbeek’s GSoC for the general direction we’re taking
> and please ask the question in a less obviously biased way.
>
>
> Thanks,
>
> --
> Aymeric.
>
> --
> 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 [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/C79B391D-DC6D-4127-BC90-C2E32DE0937B%40polytechnique.org.
> For more options, visit https://groups.google.com/d/optout.



--

Cordialement, Coues Ludovic
+336 148 743 42

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEuG%2BTahvipFS-%3D-FkCnvTmvTE_gEvpJHwOg933-xAL9p4UDAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

Aymeric Augustin
On 04 Oct 2016, at 15:53, ludovic coues <[hidden email]> wrote:

> Sorry about the way the question are formulated. Writing a rambling
> post under emotion was pretty stupid of me.

No worries. It happens :-)

--
Aymeric.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7903BF56-A26E-4931-AC6B-7157DDECCE4A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: DEP pre-proposal for a simpler URLs syntax.

tom christie
In reply to this post by ludovic coues
> About the url convention

We're not changing anything about the URL conventions, we're changing the oath syntax.
Django tends to use a trailing slash style by convention. This proposal wouldn't change that in any way.

> The only technical reason I see for enforcing the starting slash

The leading slash in the syntax is open to discussion, however I'm very strongly in favor due to two points:

* It is a strong and consistent visual indicator.
* Doing so would mean that Django and Flask share exactly the same routing syntax. (Flask enforces a leading slash)

I think there are *very* strong reasons to have a single consistent URL syntax used across the two most popular Python web frameworks.
This is a new syntax, and the capture groups have changed substantially, so I think it's acceptable that it also doesn't happen to echo the regex style wrt this particular aspect.

> The question about the old routing system is about the plan to build on top the old one.

There's nothing to stop a current or later proposal for redesigning the URL system in order to provide for non-path based routing. That's a different conversation. Nor is there anything to stop either an internal refactoring, or an alternate proposal for how to implement the described syntax. Design proposals or PRs welcome.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4011b577-4ce8-4f1f-8c04-027d5b9cc8b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
1234