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 <[email protected]>: > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. 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.
