Hello,

Sorry Adam, I'm going to argue for the opposite position on both questions ;-)

I don't think it's a good idea for add urls.py to startapp for three reasons:

a. Even though Django's built-in boilerplates (startprojet and startapp) are 
fairly minimal, I've seen many projets with the dummy models, admin or tests 
module committed in a bunch of apps, creating noise. More files will make that 
problem worse. (I'll admit I'm not a huge fan of boilerplates in general.)

b. Some developers like giving each app its own URL space. Others prefer 
keeping all URLs in a central location. Small projects can stick with the 
simplest thing that works and a central URLconf does the job up to a few dozen 
routes. Large projects, by the time they become large, have had the time to 
understand the tradeoffs and figure out what structure works best for them. I 
think startapp is most useful to people with little Django experience and 
splitting urls.py is a premature optimization for them.

c. Unlike admin.py which is autodiscovered, urls.py won't do anything until 
it's referenced from the main URLconf. It would be misleading to add a module 
that doesn't work. I think the potential for confusion may outweigh the 
usefulness.

Regarding the target directory of startproject, I'm in favor of the proposal. 
Here's the background:
https://code.djangoproject.com/ticket/17503 
<https://code.djangoproject.com/ticket/17503>
https://code.djangoproject.com/ticket/17042 
<https://code.djangoproject.com/ticket/17042>
https://groups.google.com/forum/#!msg/django-developers/RLcKN_9zKYs/NsWYq3lVFU0J
 
<https://groups.google.com/forum/#!msg/django-developers/RLcKN_9zKYs/NsWYq3lVFU0J>

The default behavior keeps biting me, even though I no longer qualify myself as 
a Django newbie, and I'm not the only one who finds it surprising. Unix 
commands operate in the current directory unless told otherwise: example: `ls` 
vs. `ls path/to/directory`.

Certainly files can be moved around after the fact — I do it every time — but 
this doesn't excuse the counter-intuitive API. I don't have the energy to argue 
for breaking backwards-compatibility here. But I'm strongly in favour of 
acknowledging this bug in the documentation (I haven't checked what it looks 
like currently).

Best regards,

-- 
Aymeric.


> On 28 May 2017, at 15:13, Adam Johnson <[email protected]> wrote:
> 
> 1. I don't see why not. Even DRF apps need urls.py files right?
> 2. I think this is a minor issue and not worth worrying about, newbies should 
> be able to move files and folders around appropriately on the filesystem. 
> It's cleaner to put things in a subdirectory as it lowers the risk of 
> overwriting existing files in the current directory.
> 
> On 27 May 2017 at 02:51, 左小龙 <[email protected] 
> <mailto:[email protected]>> wrote:
> 1. Why not create urls.py for every app when user run startapp command? I 
> think most app need urls.py except when using other framework like 
> django-rest-framework.
> 
> 2. When we run `django-admin startproject mysite` will also create an inner 
> directory call mysite which is very confuse to newbie.  Some people recommend 
> use `django-admin startproject mysite .`(comma at the last) instead. Should 
> we also recommend this in the document?
> 
> -- 
> 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] 
> <mailto:[email protected]>.
> To post to this group, send email to [email protected] 
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/django-developers 
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/87e879d8-3674-4b96-973d-f1dd0b4a1148%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/87e879d8-3674-4b96-973d-f1dd0b4a1148%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> 
> -- 
> Adam
> 
> -- 
> 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] 
> <mailto:[email protected]>.
> To post to this group, send email to [email protected] 
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/django-developers 
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0yrSVPaeqpP6X0h0ty%3DjvbgsBRgLr5EgVw7wU7DgXWRg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM0yrSVPaeqpP6X0h0ty%3DjvbgsBRgLr5EgVw7wU7DgXWRg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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/2B0669F6-501D-49C0-8104-B0BA0655043A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to