How common are "heavily nested apps"? Is there anyone else reading this who
would find this useful?
On Thursday, March 3, 2016 at 3:40:14 AM UTC-5, lamby wrote:
>
> This just made me realize that the whole problem can already be fixed from
>> the user's perspective by importing the module instea
>
> 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
>
Not entirely convinced. Firstly it's extra stuff you have to explicitly
import which seems a style regression from the "oh
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 possibl
Going off topic a little bit but.. have we considered deprecating string
based includes in favour of actually importing the urls module?
from . import myapp
urlpatterns = (
url(r'^myapp/', include(myapp.urls.urlpatterns)),
)
Then users can relatively import their nested app patterns as they wi
The current approach can lead to surprising errors if include() is called
by a helper function, rather than directly called in your urlconf. The
relative import would be resolved in relation to the module where the
helper function is defined. I'm not sure how much of an actual problem that
is i
I’m +0 on this change, for consistency with Python’s import statement.
--
Aymeric.
> On 29 Feb 2016, at 14:17, Tim Graham wrote:
>
>
> For example, within myproject.urls:
>
> urlpatterns = (
> url(r'', include('.myapp.urls')),
> )
>
> .. becomes equivalent to::
> urlpatt
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
cleane