Hi Josh, On Monday, February 29, 2016 at 11:34:18 PM UTC+1, Josh Smeaton wrote: > > Going off topic a little bit but.. have we considered deprecating string > based includes in favour of actually importing the urls module? >
I've tried to remove them as a proof of concept, but that's not possible without some small regressions and test failures. Currently, urlpatterns are loaded lazily, and when they're loaded, the complete content of the namespace is loaded. This allows you to recursively include the same URLconf, but only when you include the URLconf using a namespace (otherwise the code attempts to load every level, and you'll run into a maximum recursion depth error). This is done in the test suite as well[1], hence the test failures. I haven't been able to think of any practical use-cases, but you never know what's out there. The best I can come up with is to include an arbitrary number of positional arguments, but I think that's better handled by capturing them as one argument and splitting in the view, or even better, by using GET parameters. I don't think string based imports are much of a problem in the case of include. The import is done immediately, and the errors are clear. Deprecating does have the benefit of increased consistency and less magic, but otherwise I don't see any practical benefits. Then users can relatively import their nested app patterns as they will. > Even if we didn't deprecate string based imports I'm wary of increasing > their utility. This just made me realize that the whole problem can already be fixed from the user's perspective by importing the module instead of using string based imports. That is possible and has been possible for a long time. In that light, I don't see the benefit of supporting relative string based imports with some confusing edge-cases. [1] https://github.com/django/django/blob/eac1423f9ebcf432dc5be95d605d124a05ab2686/tests/urlpatterns_reverse/namespace_urls.py#L57 > On Tuesday, 1 March 2016 00:17:39 UTC+11, Tim Graham wrote: >> >> For example, within myproject.urls: >> >> >> urlpatterns = ( >> url(r'', include('.myapp.urls')), >> ) >> >> >> .. becomes equivalent to:: >> >> urlpatterns = ( >> url(r'', include('myproject.myapp.urls')), >> ) >> >> >> Whilst a contrived example, this can make heavy-nested apps look far, far >> cleaner. For example, within myproject.foo.foo_bar.foo_bar_baz.urls, one >> only needs to include .foo_bar_baz_qux.urls to get to the "next" level, >> rather than the significantly more unwieldy >> myproject.foo.foo_bar.foo_bar_baz.foo.bar_baz_qux.urls. >> >> ---- >> >> What do you think of this proposal from >> https://code.djangoproject.com/ticket/26288? I don't know if "nested >> apps" are very common and/or something that should be promoted with a >> change like this. >> > -- 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/e50521cf-5535-45dc-8d50-a10073de385b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
