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
--
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+unsubscr...@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/20161004184810.GC6601%40koniiiik.org.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
