O que é para você parar de usar myproduct.myproduct? O que você precisa para conseguir isso consiste basicamente em fazer isso:
django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py
e assim por diante. Ajudaria se eu dissesse views.pyque não precisa ser chamado views.py? Desde que você possa nomear, no caminho do python, uma função (geralmente package.package.views.function_name) será manipulada. Simples assim. Todo esse material de "projeto" / "aplicativo" são apenas pacotes python.
Agora, como você deve fazer isso? Ou melhor, como posso fazer isso? Bem, se você criar uma peça significativa de funcionalidade reutilizável, como diria um editor de marcação, que é quando você cria um "app nível superior", que pode conter widgets.py, fields.py, context_processors.pyetc - todas as coisas que você pode querer importação.
Da mesma forma, se você pode criar algo como um blog em um formato bastante genérico nas instalações, pode agrupá-lo em um aplicativo, com seu próprio modelo, pasta de conteúdo estático etc., e configurar uma instância de um projeto django para usar esse conteúdo do aplicativo.
Não há regras rígidas e rápidas dizendo que você deve fazer isso, mas esse é um dos objetivos da estrutura. O fato de tudo, incluindo os modelos, permitir que você inclua a partir de alguma base comum significa que seu blog deve se encaixar perfeitamente em qualquer outra configuração, simplesmente cuidando de sua própria parte.
No entanto, para abordar sua preocupação real, sim, nada indica que você não pode trabalhar com a pasta do projeto de nível superior. É o que os aplicativos fazem e você pode fazê-lo se realmente quiser. Eu costumo não fazer isso, por várias razões:
- A configuração padrão do Django não faz isso.
- Muitas vezes, eu quero criar um aplicativo principal, então eu crio um, geralmente chamado
website. No entanto, em uma data posterior, talvez eu queira desenvolver funcionalidades originais apenas para este site. Com o objetivo de torná-lo removível (mesmo que nunca o faça), costumo criar um diretório separado. Isso também significa que posso descartar a funcionalidade apenas desvinculando esse pacote da configuração e removendo a pasta, em vez de excluir um complexo as URLs corretas de uma pasta global urls.py.
- Muitas vezes, mesmo quando quero fazer algo independente, ele precisa de um lugar para viver enquanto eu cuido / o faço independente. Basicamente, o caso acima, mas para coisas que pretendo tornar genéricas.
- Minha pasta de nível superior geralmente contém algumas outras coisas, incluindo, entre outros, scripts wsgi, scripts sql etc.
- As extensões de gerenciamento do django dependem de subdiretórios. Portanto, faz sentido nomear pacotes adequadamente.
Em resumo, o motivo pelo qual existe uma convenção é o mesmo que qualquer outra convenção - ajuda quando se trata de outras pessoas que trabalham com o seu projeto. Se eu vejo fields.py, imediatamente espero que o código contenha a subclasse do campo do django, enquanto que se eu ver inputtypes.py, talvez não seja tão claro o que isso significa sem olhar para ele.