Hi Carl,
On Fri, 10 Feb 2012, Carl Meyer wrote:
Is there any reason not to drop the project name part of
DJANGO_SETTINGS_MODULE and ROOT_URLCONF, to reduce the risk of
confusion, pollution, double imports and bad practice app coding in
Django?
If you follow that quoted thread to the end, you'll find that this
problem has already been resolved in trunk :-) See
https://docs.djangoproject.com/en/dev/releases/1.4/#updated-default-project-layout-and-manage-py
for the release-notes summary.
Thanks, I had seen the patch on Trac and noticed that it was being
resolved in the direction of the "status quo", by enforcing the presence
of a top-level directory/module/package. This is the opposite of what I
was suggesting: entirely removing the top-level thing. I was curious about
the reasons for this decision, and whether the (apparently simpler)
alternative had been considered and rejected, and if so why?
For the default project layout, I chose to resolve it in favor of having
an outer "project package", as this namespaces the project better and
avoids potential top-level namespace clashes with generic names like
"settings" and "urls". However, it's easy enough to adjust the layout
and imports for your own project to eliminate that project package and
just use "import settings" and "import urls", if you prefer that.
Can you tell me more about why "potential top-level namespace clashes with
generic names like "settings" and "urls"" would be a problem?
We can always import .settings and .urls if we we want the top-level
modules, can't we?
Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
