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

[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

[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!

[Jacob Kaplan-Moss]

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

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.

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

[Aymeric Augustin]

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

-- 

Aymeric.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
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 https://groups.google.com/d/msgid/django-developers/CAK8PqJEbne2fp9X3Q1Dgr7OG3Ns54A1gqdndwCD5FXNT8j%3DXTw%40mail.gmail.com.

[Ryan Hiebert]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/D5256C17-164F-4123-B07C-7A62100AE7F1%40polytechnique.org.

[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

[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

>--
>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-develop...@googlegroups.com.
>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 https://groups.google.com/d/msgid/django-developers/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%40googlegroups.com.

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20161003221128.GB23889%40pyler.local.

[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

>To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/DF8D81E2-7370-494C-90E4-E28E0A9B3897%40polytechnique.org.

[Raphael Michel]

Hi,

Am Tue, 4 Oct 2016 00:11:28 +0200
schrieb Markus Holtermann <in...@markusholtermann.eu>:

> 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

[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

[Martin Owens]

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

[Markus Holtermann]

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

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

> --
> 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-develop...@googlegroups.com.
> 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

> 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

[Aymeric Augustin]

Hello Ludovic,

On 04 Oct 2016, at 14:25, ludovic coues <cou...@gmail.com> 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.

[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
<aymeric....@polytechnique.org>:

> --
> 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-develop...@googlegroups.com.
> 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 https://groups.google.com/d/msgid/django-developers/C79B391D-DC6D-4127-BC90-C2E32DE0937B%40polytechnique.org.

[Aymeric Augustin]

On 04 Oct 2016, at 15:53, ludovic coues <cou...@gmail.com> 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.

[Tom Christie]

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

[Sjoerd Job Postmus]

On Oct 4, 2016 15:53, ludovic coues <cou...@gmail.com> wrote:
>
>
> 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.

To be fair, the current routing system is reasonably loosely coupled to the rest of Django. If the simpler version were to be built on top of the old system, it would be tightly coupled to the old system, but would not make it any harder to replace it with another 3rd party module than currently is possible.

As I documented in my blog post: if you want you can mostly replace the current URL routing, all you need is to have a class that defines `resolve`. Reversing URLs is a different matter, and I hope to work on a pull request to change the URL reversing to make it also a bit more pluggable.

[Michal Petrucha]

On Tue, Oct 04, 2016 at 09:21:33AM -0700, Tom Christie wrote:
> > 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.

I'm not sure if this is what Ludovic had in mind, but I can see how
the leading slash could become internally inconsistent when composing
patterns using include(). Let me illustrate with one example that
consistently uses slashes at the beginning and at the end of each
pattern (beginning, because it's enforced by your proposal, end,
because I want all URLs to end with a slash, as is the convention with
Django)::

library_patterns = [
url('/', book_list),
url('/<int:book_id>/', book_details),
]

main_paterns = [
url('/library/', include(library_patterns)),
]

The problem is that now just prepending the string from main_patterns
to each pattern in library_patterns will result in double slashes in
patterns ('/library//', '/library//<int:book_id>/'). So the resolver
will probably have to be smart, and discard the leading slash from
every pattern, which is a departure from the current semantics of
pattern composition, where you can just concatenate the individual
parts in a hierarchy of urlpatterns to get the effective pattern for
any view. Also, I can imagine this could be somewhat confusing. (“Why
do I have to write the same slash in both patterns? Which pattern is
the one that actually matches the slash? What if I want the URL to
actually contain two slashes?”)

The other option would be to retain the semantics of just
concatenating patterns, but in that case, you'd have to omit the
trailing slash in the inclusion pattern, turning it into '/library'.
In this case, it could be argued that we lose a bit of consistency,
because depending on whether a pattern is an inclusion, or a leaf
pattern, you'd have to either omit, or include the trailing slash
(if you want to stick to the popular convention of all URLs ending
with a slash).

What's worse with this option is that you'd have to know whether the
patterns you're including use the regex-based convention of always
matching the separating slash in the parent pattern, or the
constraints of the new typed patterns, and based on this either add a
trailing slash, or not. Then you'd end up with patterns like this, and
there goes any semblance of consistency::

urlpatterns = [
# Including new-style typed patterns.
url('/registration', include('registration.urls')),
# This would need to remain without a leading slash for
# backwards compatibility.
url('/admin/', admin.site.urls),
# Third-party package that chooses to stick to regex patterns.
url('/social/', include('social.apps.django_app.urls')),
]

I'm not sure what the solution to this is in the Flask world – I would
guess that they just don't use trailing slashes in URL prefixes, but
Django has already been promoting the opposite pattern for about a
decade...

Does this make sense? Personally, I'm not very convinced by either
option...

Cheers,

Michal

[Tom Christie]

Yup, good points there. I wasn't really considering `include` at that point.

Definitely some awkwardnesses that need thinking about there.

urlpatterns = [

    path('', homepage),

    path('users/', users_list)

]

Looks very odd to me, since those are not actually valid URL paths. ('/' and '/users/' are the actual URL paths)

Anyways, something to mull over. That and the import names are probably the two areas that'll need resolutions.

[Sjoerd Job Postmus]

In all fairness, it's actually

magic_urlpatterns_you_will_never_see = path('/', include(the_urlconf))

Django uses the magic_urlpatterns_you_will_never_see, which already includes that slash.

My recommendation would be to forgo the starting slash. In Flask you provide the full route ("absolute path") to your view, in Django the relative path. Relative paths don't start with a slash.

--

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-develop...@googlegroups.com.
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 https://groups.google.com/d/msgid/django-developers/70d64bf4-6ba9-444f-b161-165e6607d257%40googlegroups.com.

[Tom Christie]

I've iterated on the pre-proposal, with what I think represents the best options to date.

https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

The updates are:

* Using a different name for the syntax: `path()`.

* Dropping the leading slashes.

* Simplifying the "unintended errors" section.

At some point I'll likely start working towards a validation of this. (Other takers also most welcome.)

If/when we decided to submit a draft DEP for more in-depth review & consideration, we'll need a shepherd for the proposal. Any takers? (Must be someone from the core team, with commit access.)

Cheers all,

  Tom

[Sjoerd Job Postmus]

+1. Looks finished to me. I'd like to contribute on this one way or another. I'll try to make sure `django-simple-url` is as compatible with this as possible. If need be I'm willing to change the current license if it's not compatible with inclusion in Django core.

[Emil Stenström]

Just a short note from the one that started the first thread after finding the regexps hard to read:

Thanks for this Tom, this is exactly what I was looking for! <3

[Robert Roskam]

Hey Tom,

I really like your current implementation. I think it's an elegant solution to a complex problem, and I like that you looked at Flask for some inspiration. 

I thought that to round out the discussion I'd do a quick comparison to other frameworks. (I've added in slug examples):

Django

urlpatterns = [     
    url(r'^articles/2003/$', views.special_case_2003),
    url(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),
    url(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$', views.month_archive),
    url(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<day>[0-9]{2})/$', views.article_detail),
    url(r'^articles/(?P<slug>[\w-]+)/$', views.slug_view),
]

DEP

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

Flask

Doesn't really have the idea of putting all your routes in one spot. So pardon the silly example.

    
@app.route('articles/2003/') 
def special_case_2003():
	pass

@app.route('articles/<int:year>/') 
def year_archive(year):
	pass

@app.route('articles/<int:year>/<int:month>/') 
def month_archive(year, month):
	pass

@app.route('articles/<int:year>/<int:month>/<int:day>/') 
def article_detail(year, month, day):
	pass

@app.route('articles/<string:slug>/')
def slug_view(slug):
	pass




Bottle

It's basically Flask (big surprise).

@route('articles/2003/') 
def special_case_2003():
pass

@route('articles/<year:int>/')
def year_archive(year):
	pass

@route('articles/<year:int>/<month:int>/')
def month_archive(year, month):
	pass

@route('articles/<year:int>/<month:int>/<day:int>/') 
def article_detail(year, month, day):
	pass

@route('articles/<slug:string>/')
def slug_view(slug):
	pass




Pyramid

This one is kind of interesting. They don't have any built in validators. And they call their equivalent predicates, and their usage is far more board. 

config.add_route('special_case_2003', 'articles/2003/')
config.add_route('year_archive', 'articles/{year}/')
config.add_route('month_archive', 'articles/{year}/{month}/')
config.add_route('article_detail', 'articles/{year}/{month}/{day}/')
config.add_route('slug_view', 'articles/{slug}/')
config.scan()

Robert Roskam

[Robert Roskam]

Hey All,

Sorry all. I accidentally submitted my message somehow.

I wanted to say that I like the direction Django is going compared to the other Python frameworks for its routing. I've looked at Express.js, angularjs, rails, and MVC.NET as well. And Django is definitely the easiest to read among them.

I think this syntax offers both simplicity in not missing dumb stuff like the leading ^ and the trailing $, but it also lets us work toward more expressive routing patterns in the future.

Robert Roskam

[Ola Sitarska]

I'm quite excited about this: it's definitely gonna solve some of the pain points we're facing when teaching Django to Django Girls! Big +1 to include it in core. 

I recently started dabbling a bit in Rails, and wondered if it'd be possible here to get rid of the converter in the syntax at all, or have a default one if none is provided. For complete beginners, even figuring out what's this `int` or `string` is again is another thing they have to think of, and it might be beneficial to think of the really really really simple way. Here is how Rails do it, and I was quite surprised how easy that is. Haven't looked into any implementation details of current urls or new simple urls, so this idea might be a completely wrong one, I admit :) 

Good job, I'm really happy see this being worked on! 

Cheers,

Ola

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

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/db1f38e2-3716-41d0-870e-ea7b84d0cfc6%40googlegroups.com.

[Tom Christie]

> wondered if it'd be possible here to get rid of the converter in the syntax at all, or have a default one if none is provided.

Actually yes, I'd not noted in the proposal but you can also simply use eg.

    path('users/<id>/')

By default that'll give you the 'string' convertor. (Accepts any text without a slash.)

I've updated the document to reflect this.

[Ola Sitarska]

That is *awesome* :)

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/e62c279f-4f0b-4cbc-9f98-36650407835e%40googlegroups.com.

[Matthias welp]

Hi,

I may be late, but using 'path' as a name for this function is in my
opinion not recommended. It would shadow the stdlib os.path,
albeit not as a library, but as a function.

Using 'route' would be more interesting in my opinion, but shadowing
the Channels 'route' function (which has a very similar interface, but
different enough to confuse people) makes this also not really doable.

I think changing the behaviour of 'url' based on a boolean flag is nicer
in my opinion, as you'd then still have the resonation between the
'{% url %}' template tag and what you put in your urls.py (and no, I
really don't want to rename my files to paths.py). An alternative to

url with easy flags is, well, just calling it 'easy_url'.

TLDR: don't call it 'path', keep 'url' and add flags or call it  'easy_url'
(which may be an alias for url with true flag for easy mode).

-MMeent

[Florian Apolloner]

On Thursday, October 6, 2016 at 1:30:38 PM UTC+2, MMeent wrote:

It would shadow the stdlib os.path, albeit not as a library, but as a function.

I do not think that os.path will usually interfer with url routing, so I don't take that as an argument. In the end, path is perfectly suitable, since we are actually matching on the path and might (?) allow other functions like subdomain() in the future. It would really be interesting to end up with something like:

urlpatterns = [
  subdomain('<user>') + path('/<page:int>/')
]

or similar
urlpatterns = [
  subdomain('<user>,
    path('/<page:int>/'),
    …more paths for that subdomaiin
  )
]

Cheers,
Florian

[Tim Graham]

Hi Tom,

I'm not sure how the timing will work out, but an option could be to target this for inclusion in Django 2.0 but make the necessary fixes in Django 1.11 to allow this to exist as a third-party app in the meantime. That would allow it some time to get some real world usage and undergo more rapid iteration before it's included in Django.

I thought of one thing for the implementation checklist: the simplify_regex() function in admindocs should probably be a method of the URLPattern class.

https://github.com/django/django/blob/979ea95608176e9c88678fd4d8a096c29654b5f3/django/contrib/admindocs/views.py#L432-L448

You can list me as the DEP shepherd if needed.

[Tom Christie]

> an option could be to target this for inclusion in Django 2.0 but make the necessary fixes in Django 1.11 to allow this to exist as a third-party app in the meantime.

Interesting idea, yup. I'm open minded at this stage.

Other hurdles to get past first, so let's see how we go before calling a judgement in that. Certainly worth having as an option.

> You can list me as the DEP shepherd if needed.

Grand. Let's run with that then, unless anyone else (from the core team) particularly wants to step up.

Thanks,

    Tom

[Sjoerd Job Postmus]

What is the current status of this pre-proposal? Is there anything I can help with?

[Tom Christie]

> What is the current status of this pre-proposal?

I think it's ready for some initial work to validate the approach.

I've got some time available for this in the near future, given that I'm currently on open source work full time.

> Is there anything I can help with?

If you also wanted to get involved I'd suggest considering:

A PR for the DEP, taking it from the current markdown Gist, into a properly formatted Rst document.

A PR for any of the implementation tasks listed (all fairly separate pieces of work) to get things moving. (Things may still change once the DEP starts to be fully reviewed, but there's no great harm in getting started.)

Cheers,

  Tom

[Sjoerd Job Postmus]

So I reformatted the markdown to rST, as required by the DEP process, and created a pull request.

https://github.com/django/deps/pull/27

(And I see the first review is already in too!)

[Pete Wildsmith]

I agree that those look odd. As far as the end-user is concerned, though, their project's urls module is the root. Does accepting (and removing) a leading slash have a negative side-effect that I'm not aware of? Enforcing its absence seems to expose an implementation detail.

[Paul Egges]

Actually, we do something very similar to this in a routes.py for a flask app. Except instead of "pass" we call a function that has been imported.

Paul

Flask

Doesn't really have the idea of putting all your routes in one spot. So pardon the silly example.

    
@app.route('articles/2003/') 
def special_case_2003():
	pass

@app.route('articles/<int:year>/') 
def year_archive(year):
	pass

@app.route('articles/<int:year>/<int:month>/') 
def month_archive(year, month):
	pass

@app.route('articles/<int:year>/<int:month>/<int:day>/') 
def article_detail(year, month, day):
	pass

@app.route('articles/<string:slug>/')
def slug_view(slug):
	pass

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/1177f3c9-fe36-41b4-b6b3-69daae8d8409%40googlegroups.com.

[Emil Stenström]

Hi everyone!

I got curious to the current state of this work so I thought I save everyone some work and give you a bunch of links:

• Main PR where the work is being done: https://github.com/django/django/pull/7482 - Seems there are conflicts with master that needs to be resolved.
• An update to all documentation to use path() instead of url(): https://github.com/django/django/pull/7542
• PR for an updated DEP 0201: https://github.com/django/deps/pull/34

Tome Christie and Sjoerd Job Postmus have done a hell of a good job here! I'm trusting that they ask for help if there's something the community can do.

If this gets merged it will be one significant improvement to Django!

/Emil

[Tom Christie]

> I'm trusting that they ask for help if there's something the community can do.

Personally I've got other priorities at the moment, so it's not something I'm working on or looking at.

I do think it's a really nice bit of low hanging fruit tho, just needs someone to do a bit of work on shepherding it through.

[Emil Stenström]

Tom: Very much agree that this is low hanging fruit, especially since the two of you have already done most of the work! :)

Thanks for your quick reply, then I know.

I talked to Sjoerd separately. He is also very busy at the moment, but was working on getting merge conflicts resolved soon. He will also post a list of things that are still missing, but spontaneously thought that this list would be short.

What's missing now is someone from the core team that can help push this into being ready for master. Is there someone that would like to be the hero for everyone teaching django to beginners? :)

[Aymeric Augustin]

Hello Emil,

On 2 May 2017, at 07:39, Emil Stenström <e...@kth.se> wrote:

What's missing now is someone from the core team that can help push this into being ready for master. Is there someone that would like to be the hero for everyone teaching django to beginners? :)

Since I'm between two jobs, I have some availability this week and next week. Offer expires May 12th, 2017 ;-)

I haven't read the whole thread again, but as far as I understand, it's mostly a matter of carefully reviewing the DEP and the patch (once you update them), isn't it?

Thanks for pushing this forwards,

-- 

Aymeric.

[Sjoerd Job Postmus]

On Tuesday, May 2, 2017 at 7:39:06 AM UTC+2, Emil Stenström wrote:

I talked to Sjoerd separately. He is also very busy at the moment, but was working on getting merge conflicts resolved soon. He will also post a list of things that are still missing, but spontaneously thought that this list would be short.

Just a quick list of things I think/know missing:

• There are probably some simple converter implementations missing (FloatConverter, IntConverter, UUIDConverter, etc), and bikeshedding might need to happen on the exact implementation (what regex to use). Also, these could be added after the main logic is already completed.
• The more complex part is (I think) figuring out how to deal with cases where we have a `path('/<something:int>', include(other_urls))` and `other_urls` also has a `path()` mentioning `something`. However this might just be my perfectionism and paranoia seeing edge-cases where there are none, or are sufficiently "edge" cases that we can suffice with a "just don't do it!".
• Some positive yes/no on whether or not this is an actual desirable feature for Django from the core team.
• Like I mentioned to Emil, I *think* this is "everything" that remains, but I might be missing a few things.

Anyway, a careful review like Aymeric Augustin is suggesting might probably turn up a few more things that are missing.

Emil: Thanks for pushing this forwards again, it got off the top of my mind, and it is good to have it back in focus again.

[Ola Sitarska]

Hi all,

From my personal perspective, I'd love to have that feature in Django. It'd make a significant difference especially for beginners learning Django, as I know that during Django Girls workshop, teaching newcomers regex is one of the most annoying and difficult parts of learning how Django works. 

If there is anything I can do to help, I'm very interested. I'll try to find some time today to review current pull requests and see if there is a way for me to contribute. 

Thanks to everyone who has worked on this so far!

Ola

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/c39a40a0-25b3-4a7b-b002-767fadb38db7%40googlegroups.com.

[Tom Christie]

> Some positive yes/no on whether or not this is an actual desirable feature for Django from the core team.

We've positive feedback from at least Jacob, Ola, Aymeric, and myself, so I'd broadly assume we're good there, so long as there's not any specific blockers that emerge.

I'd expect there could(?) end up being some awkward aspects in consensus around how we approach the documentation, but we'll see how that progresses.

[Sjoerd Job Postmus]

Yes, I see now. It's been a while since I last browsed through the thread, and was trying to just get it a bit closer to "completed" today.

Tests all pass, but I'm sure it could do with some improvements.

Ola, Aymeric: Thank you both for also offering up a segment of your time to help push further this feature. It's greatly appreciated.

[Marten Kenbeek]

 

• The more complex part is (I think) figuring out how to deal with cases where we have a `path('/<something:int>', include(other_urls))` and `other_urls` also has a `path()` mentioning `something`. However this might just be my perfectionism and paranoia seeing edge-cases where there are none, or are sufficiently "edge" cases that we can suffice with a "just don't do it!".

 The current resolver doesn't really handle this either. When resolving, the current implementation simply passes on the outermost capture group to the view. When reversing you can only pass in a single value that must match both groups. If you can solve it, great, but I think it's sufficient to let the underlying resolver handle it the same way. 

[Sjoerd Job Postmus]

On Wednesday, May 3, 2017 at 12:35:30 AM UTC+2, Marten Kenbeek wrote:

 

• The more complex part is (I think) figuring out how to deal with cases where we have a `path('/<something:int>', include(other_urls))` and `other_urls` also has a `path()` mentioning `something`. However this might just be my perfectionism and paranoia seeing edge-cases where there are none, or are sufficiently "edge" cases that we can suffice with a "just don't do it!".

 The current resolver doesn't really handle this either. When resolving, the current implementation simply passes on the outermost capture group to the view. When reversing you can only pass in a single value that must match both groups. If you can solve it, great, but I think it's sufficient to let the underlying resolver handle it the same way. 

Yes, that's somewhat what I expected as well, just wasn't as sure. I *think* it's probably better to make a check that the capture groups do not overlap than to write code to deal with that elegantly. But that could probably happen in a different PR.

[Sjoerd Job Postmus]

Hi all,

Due to scheduling, I have not been able to give this the attention I would like to give it, and I don't see myself freeing up a significant amount of time to give it the final push forward before the feature freeze on September 18th.

I did a final review of my changes. Though there are some things that might need a bit of cleaning up, I have the feeling the pull request (https://github.com/django/django/pull/7482) is in a reasonable state. There are a lot of comments by me about things that might be improved, though. There's also a TODO list (https://github.com/django/django/pull/7482#issuecomment-305482442) about things that still need doing.

Based on the check-list, I think the following items remain:

- Documentation the new syntax (but Tom already has a PR open for that), but that should only be picked up after this feature is merged/mergeable.

- Updating existing documentation (maybe even the tutorial?) to use the new syntax. I think that's also included in Tom's PR.

- Extra tests. There are dedicated tests already, but given such a core feature I would feel more comfortable if there were even more tests.

- Not mentioned in the checklist, but performance concerns should also be checked [1].

Personally, I would love for this feature to land in Django 2.0, but I'm doubtful that I can push it further myself, and would be greatly appreciative if somebody were willing to help push it forward.

[1]: Previously, the code used `LocaleRegexDescriptor`, which acted as `@property` when the regular expression was lazy, while if it is a pure string it would set the attribute directly as an optimisation trick. This might need to be replicated.

Regards,

Sjoerd Job

[John Griebel]

Hi Sjoerd,

I too would love to see this feature in Django 2.0; in fact, I've been following its progress quite closely. I would love to help out with it and have the necessary time to do so.

John Griebel | Senior Backend Engineer | 3Blades.io | 814-227-4213

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/d75698e7-e75e-4719-a000-4172f3ed1082%40googlegroups.com.

[Emil Stenström]

John: Awesome! Do you need anything to get started or is Sjoerd's review comments and todolist enough?

On Friday, 28 July 2017 15:03:12 UTC+2, John Griebel wrote:

Hi Sjoerd,

I too would love to see this feature in Django 2.0; in fact, I've been following its progress quite closely. I would love to help out with it and have the necessary time to do so.

John Griebel | Senior Backend Engineer | 3Blades.io | 814-227-4213

On Thu, Jul 27, 2017 at 5:06 PM, Sjoerd Job Postmus <sjoe...@sjec.nl> wrote:

Hi all,

Due to scheduling, I have not been able to give this the attention I would like to give it, and I don't see myself freeing up a significant amount of time to give it the final push forward before the feature freeze on September 18th.

I did a final review of my changes. Though there are some things that might need a bit of cleaning up, I have the feeling the pull request (https://github.com/django/django/pull/7482) is in a reasonable state. There are a lot of comments by me about things that might be improved, though. There's also a TODO list (https://github.com/django/django/pull/7482#issuecomment-305482442) about things that still need doing.

Based on the check-list, I think the following items remain:

- Documentation the new syntax (but Tom already has a PR open for that), but that should only be picked up after this feature is merged/mergeable.

- Updating existing documentation (maybe even the tutorial?) to use the new syntax. I think that's also included in Tom's PR.

- Extra tests. There are dedicated tests already, but given such a core feature I would feel more comfortable if there were even more tests.

- Not mentioned in the checklist, but performance concerns should also be checked [1].

Personally, I would love for this feature to land in Django 2.0, but I'm doubtful that I can push it further myself, and would be greatly appreciative if somebody were willing to help push it forward.

[1]: Previously, the code used `LocaleRegexDescriptor`, which acted as `@property` when the regular expression was lazy, while if it is a pure string it would set the attribute directly as an optimisation trick. This might need to be replicated.

Regards,

Sjoerd Job

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.

[John Griebel]

I think the review comments and the Todo list should get me off to a good start. I'm sure I'll have a few questions along the way as I've contributed to other open source projects before, but not Django. I spent some time last evening reading the contribution docs and getting my environment set up.

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

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/12ac3285-5d09-4fe1-bbf2-b34c75150724%40googlegroups.com.

[John Griebel]

Hi Sjoerd, Emil (and everyone else),

I wanted to give a quick update here so you all have some visibility into the progress being made. I have begun by working on the "Update the tests throughout, updating to the new style wherever possible." in Sjoerd's check list just to get my feet wet and familiarize myself with the code base a little more, how path() works, etc. 

At this point I've converted the URL configs for all test packages with the following exceptions:

1.) auth_tests - About 16 tests are still failing, all related to password-reset. 

2.) check_framework - path() makes some URLs configurations valid that are not valid with url() such as including '$' in an include, etc. For the time being, I have elected not to convert the URLs that would be valid with path() but not url(). I am sure this merits some discussion. If it's already been discussed and I missed it, just let me know.

3.) generic_views - 16 tests are failing, all related to date tests. I suspect the majority of problems here will be fixed by getting urls.py exactly correct. I do think there may have to be a small change to the _date_from_string method in /generic/dates.py, however.

4.) i18n - I haven't dealt much with i18n in the past so I've left this one for a bit later.

5.) messages_test - Only one failure that I need to figure out.

6.) urlpatterns_reverse - Should these be left as is, and similar tests for path() be created since url() will not be deprecated immediately? 

7.) view_tests - I see Sjoerd already made some small changes here and wanted to confirm that the rest of the URL conf was not left unconverted intentionally before converting them myself.

Feedback on 6 and 7, in particular, would be great.

Thanks,

John Griebel | Senior Backend Engineer | 3Blades.io | 814-227-4213

[John Griebel]

Hi All,

My day job has gotten unexpectedly busy, and it seems I've taken on more than I can handle on the code side of things for this DEP. If someone else can help out, that would be great. I can provide some help with the documentation if it's still needed, though it seems like Tim's PR is pretty complete.

[Sjoerd Job Postmus]

Hi John,

It's a bit unfortunate that I can't find any trace of your changes. They are probably on your local machine, so I can't see any of the changes you have made or the errors they cause.

Do you believe the problems you are running into come from a bug in the path() implementation, not yet fully understanding it, or something else?

Also, I think the changes to all the other tests URLs is a "nice to have" but not necessarily a merge-blocker. In fact, letting the old syntax remain tested is still important.

Some more remarks inline.

Regards,
Sjoerd Job

On Tuesday, August 1, 2017 at 5:40:58 PM UTC+2, John Griebel wrote:

Hi Sjoerd, Emil (and everyone else),

I wanted to give a quick update here so you all have some visibility into the progress being made. I have begun by working on the "Update the tests throughout, updating to the new style wherever possible." in Sjoerd's check list just to get my feet wet and familiarize myself with the code base a little more, how path() works, etc. 

At this point I've converted the URL configs for all test packages with the following exceptions:

1.) auth_tests - About 16 tests are still failing, all related to password-reset.

It would be great to have some info on the failure: an exception, error, ?

 

2.) check_framework - path() makes some URLs configurations valid that are not valid with url() such as including '$' in an include, etc. For the time being, I have elected not to convert the URLs that would be valid with path() but not url(). I am sure this merits some discussion. If it's already been discussed and I missed it, just let me know.

In the path() syntax, a dollar sign is interpreted as matching a literal dollar sign, not as in "end of string".

 

3.) generic_views - 16 tests are failing, all related to date tests. I suspect the majority of problems here will be fixed by getting urls.py exactly correct. I do think there may have to be a small change to the _date_from_string method in /generic/dates.py, however.

would love to see the test failures.

 

4.) i18n - I haven't dealt much with i18n in the past so I've left this one for a bit later.

5.) messages_test - Only one failure that I need to figure out.

Kindly share with us.

 

6.) urlpatterns_reverse - Should these be left as is, and similar tests for path() be created since url() will not be deprecated immediately?

in urlpatterns_reverse I have left most testing as-is, because I think it is important still for re_path (url) to be validated. Should probably be left untouched.
 

[Sjoerd Job Postmus]

Hi all,

Here a minor status update regarding the pull request, and a huge request.

I believe the pull request is feature complete. Marten Kenbeek has proposed some changes to the code which I have accepted and merged into the original pull request.

The pull request itself can be found at https://github.com/django/django/pull/7482

However, and here comes the huge request: the pull request needs a review from someone with the authority to merge it into the django/django github repository. Since the Django 2.0 feature freeze is coming soon, it would be greatly beneficial if that review could happen on short notice. If any concerns arise, I hope to be able to resolve those before the freeze, but that does depend on when the concerns are being raised.

Yes, I know this is a big ask, but I would greatly appreciate any and all effort made to push this feature to the finish.

Kind regards,
Sjoerd Job Postmus

[Tim Graham]

Is there any more documentation than https://github.com/django/django/pull/7542? It doesn't look very complete:
* Release note are missing.
* Documentation for url() shouldn't be removed -- as far as I know, there's no plan to deprecate it. It should be as valid alternative (i.e. error messages should mention "path() or url()" not just " path()") shouldn't it?
* Documentation for path() and the type converters is missing.

[Tom Christie]

I've started to address some of the missing documentation aspects for this, here... https://github.com/django/django/pull/9072

I'll put in a bit more time tomorrow & friday and aim to make sure that it's reviewable by that point.

It's a bit of a tough one to have to review right up against the alpha deadline, so it's worth shouting out if there are any other obvious blockers

that'd need resolving before being able to take a call on it.

Cheers all,

  Tom

[Tim Graham]

Given the patch's current state, I'm feeling a bit overwhelmed at the prospect of reviewing it in a day or two. I didn't do a good job of communicating this release cycle, but in the past, I've set a soft deadline of two weeks before the alpha deadline for huge patches to be complete so that reviews don't have to be rushed.

[Aymeric Augustin]

2017-09-13 17:51 GMT+02:00 Tim Graham <timog...@gmail.com>:

Given the patch's current state, I'm feeling a bit overwhelmed at the prospect of reviewing it in a day or two. I didn't do a good job of communicating this release cycle, but in the past, I've set a soft deadline of two weeks before the alpha deadline for huge patches to be complete so that reviews don't have to be rushed.

Hello,

Given that several people contributed to the PR over a period of more than a year and that the feature is moderately complicated, I'm quite confident in the code. I reviewed it again last weekend and it looked ready to me. The docs aren't ready yet but I'm sure we can complete them during the alpha period if needed.

Perhaps we can find a compromise to ship this feature in the alpha with minimal docs and complete the docs later?

Best regards,

-- 

Aymeric.

[Claude Paroz]

Perhaps we can find a compromise to ship this feature in the alpha with minimal docs and complete the docs later?

I'm in favour.

Claude

[Tim Graham]

Okay, I'll work on the patch and make it my top priority.

[Sjoerd Job Postmus]

Hi all,

I have not mentioned this so far in public channels. However, I will not really able to spend a lot of time on this PR for the upcoming days due to my son's birthday coming up this Saturday.

I will keep an eye on the pull request and comments, and reply to the best of my ability.

Thank you all for the willingness to push this forward at the last minute, but I can understand if it is a bit too much to handle in a short timeframe.

If after this weekend there is more work that needs to be done, I'll happily put in the effort.

Kind regards,

Sjoerd Job

--

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-develop...@googlegroups.com.
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 https://groups.google.com/d/msgid/django-developers/ada721d9-50f9-42e8-97eb-d4fbb073bddf%40googlegroups.com.

[Tim Graham]

Hi,

Tom got sick and hasn't been able to work on the documentation as he'd hoped. If anyone wants to help, I left some TODOs (denoted by XXX) on the pull request: https://github.com/django/django/pull/9072. I'll be offline tomorrow morning (EDT) but I hope to resume work on it around 1700 UTC tomorrow. Anyone else is welcome to contribute until then (or even after that... I can always work on other things). Just coordinate here so we don't duplicate effort.

I've spent most of the past two days doing cleanup on the corresponding code changes (https://github.com/django/django/pull/7482). I don't have any big todos remaining there besides giving it a review for cosmetic improvements.

Thanks!

[Sjoerd Job Postmus]

Thank you Tim for all the hard work you have put into this!

In your opinion, do you think it will be ready/merged before the big freeze?

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a0d798b3-2177-433b-a1fb-253ca1b0442e%40googlegroups.com.

[Tim Graham]

Yes, that's my plan.

[Tim Graham]

Thanks Shai for helping out with the documentation. He pushed a commit to Tom's branch and also left this work in progress: https://github.com/shaib/django/commit/f1877751df597f6f26fc90b01f32adee1893cf50. Yesterday, Tom told me he hoped he'd be able to put in some time on this on Sunday. I won't have much time to help tomorrow but I'll plan to look at it on Monday and hopefully merge it in.

[Emil Stenström]

Hi everyone!

As the original poster of this idea I just wanted to give a big thanks to everyone involved. We're just days away from having the new URL routing syntax in Django 2.0!

Just like last year I will again be a teacher at the beginners web development course I teach once a year. We use Django because of its flexibility and I of course hope that the students will get the skills to build all kinds of sites, not just the quiz site they build in the course. The trickiest part of the course is regular expressions. They look like hieroglyphs to people seeing them for the first time, and as they were needed even for the simplest of views there was no way around adding them to the teaching material.

On Wednesday I will again hold the lecture on Django, and this time (hopefully!) the alpha version of Django 2.0 will be released, and I will have them install that instead of the stable one. I will just strike everything about regexes from the lecture, and be able for focus on more important things.

Again: Thank you so much for all your hard work, and for keeping Django awesome!



On Monday, 3 October 2016 12:24:04 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: 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