-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/10/2012 08:25 AM, Chris Wilson wrote: > 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?
The status quo, as you noted, was "confusion, pollution, double imports and bad practice app coding". Resolving this was the important step; which direction it was resolved is a minor issue in comparison. I did consider the alternative, but only briefly, as I think namespacing is clearly better practice. In the lengthy django-developers thread about the issue, nobody raised or advocated the non-namespaced option (AFAIR). >> 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? If things were set up in the way you are advocating, your Django project's settings.py and urls.py would _be_ top-level modules, and they would either mask or be masked by other top-level modules on sys.path named "settings" or "urls", depending on sys.path ordering. Namespacing the project is more explicit about what you are importing, and avoids this possibility. > We can always import .settings and .urls if we we want the top-level > modules, can't we? I can't figure out what you are suggesting here. "import .module" is not legal syntax. "from . import module" is the opposite of importing a top-level module; it's explicitly requesting a module relative to the current package instead of a top-level module. In fact, if we followed your suggestion and eliminated the project package, "from . import settings" or "from . import urls" would be impossible; you can never import top-level modules that way, Python will give you a "ValueError: Attempted relative import in non-package." Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk81PMEACgkQ8W4rlRKtE2dgMACaAtfLhyjH4U3HBrotUtzg1FhO cM0An2uKcQDpNsdz+89cROBOsRXeDwsY =8K6l -----END PGP SIGNATURE----- -- 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.
