you know what reminds me of Perl ? this:
>>> from django.template import Context Traceback (most recent call last): File "<stdin>", line 1, in ? [...snip...] EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined.
theres nothing "loose" about that, id characterize it more as "arc-welded to a hardcoded idea of runtime configuration".
NOOO! not the P-word, NOOOOO!
at the same this this is a straw-man argument,
seriously do you think it would be difficult to load the config from another file? As of now very few people would want to use the Django templating system outside of Django. And since there are already lots of settings needed to run a webapp, why not keep them in the same python file as the rest. Is your problem that the setting are in a python file? That is a different issue altogether and many would prefer Python to some kind of configuration mini-language.
In the end this whole discussion comes down the argument of the whole being more valuable than the sum of parts. For any subpart of Django there is a python module/package that is "better". Yet no one has put together a whole package like Django did.
Here is another tidbit, the stuff works, I used cherrypy, paste whatever and you know what, over the long term eventually each had shown some very serious problems, that come from them being more about the concept rather than a program that you need to make a living off. It will take years to iron out those kinds of problems.
Django works, it will hold up in traffic, it will not blow up in your face. That quality it is far superior to any other. Interoperability, reuse, decoupling are fine in theory, in practice adhering to them too strictly just makes life more difficult.
if i read you correctly, you agree with my sentiment that django's components are not very loosely coupled, your argument being essentially, "so what ? it works." that is completely fine, and im glad django is there, running very well, and attracting lots of new people to Python. its just that, there are definite advantages to componentized and environment-agnostic architectures, and im glad the community has now accepted that there will always be multiple web framework approaches (in constrast to the calls for "one true framework" a couple of years ago) so that those of us who want them can choose to use our own frameworks like Pylons which make this a priority.