Bug in django\template\__init__.py ??

[Johan]

Hi. In django\template\__init__.py on line 54 there is a line of
code : from django.conf import settings. Firstly there is no
settings.py file in django\conf, ther is however a file called
global_settings.py. In my context the is issue is fxed by changing the
line to from django.conf import global_settings as settings. I am
wanting to use the template engine outside the context of a django
project so I would not have a settings file anywhere on my path. I am
assuming that the code works in a project context since the project
would import settings and this 'broken' import would just fail
silently ?? Is this a bug? Is my fix going to break anything else?

[Russell Keith-Magee]

What you are reporting is not a bug. You need to look closer at what
is happening with django.conf. django/conf/__init__.py contains a
variable named settings that is the lazy evaluator of the setting
file. THis is the object that is obtained when you call 'from
django.conf import settings"

Your "fix" will break quite a bit of code - including, potentially,
your own. It would results in the template system only ever using the
global defaults. This wouldn't be a problem, except for the fact that
there are a couple of settings that affect the way that templates are
rendered.

Django's dependence on DJANGO_SETTINGS_MODULE is an oft-lamented
problem. Suggestions on how to address this constraint are most
welcome. However, it isn't a simple problem to fix.

Yours,
Russ Magee %-)

[Waylan Limberg]

On Thu, Oct 29, 2009 at 10:37 AM, Johan <djjo...@gmail.com> wrote:
>
> I am
> wanting to use the template engine outside the context of a django
> project so I would not have a settings file anywhere on my path.

This is documented here:

http://docs.djangoproject.com/en/dev/topics/settings/#using-settings-without-setting-django-settings-module

> I am
> assuming that the code works in a project context since the project
> would import settings and this 'broken' import would just fail
> silently

Pay special attention to the last section (Either configure() or
DJANGO_SETTINGS_MODULE is required) of the docs linked above. As
Russell mentioned settings is lazy so you don't get an import error
but you will get a RuntimeError if settings have not been configured
properly when you actually try to use your templates.
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

[Waylan Limberg]

Doh' sorry that is wrong. Actually you do get an ImportError - but not
until the settings are actually accessed (being lazy and all). The
RuntimeError is if you call settings.configure() more than once. Thus,
the importance of reading that section carefully. :-D

[Johan]

Thanks for the quick reply. I discovered exactly what you said about 2
seconds after pressing the submit on my query.

On Oct 29, 4:50 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

[Johan]

Thanks. This link is exactly what i need.

On Oct 29, 5:07 pm, Waylan Limberg <way...@gmail.com> wrote:

> On Thu, Oct 29, 2009 at 10:37 AM, Johan <djjord...@gmail.com> wrote:
>
> >  I am
> > wanting to use the template engine outside the context of a django
> > project so I would not have a settings file anywhere on my path.
>
> This is documented here:
>

> http://docs.djangoproject.com/en/dev/topics/settings/#using-settings-...

[mrts]

On Oct 29, 4:50 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

> Django's dependence on DJANGO_SETTINGS_MODULE is an oft-lamented
> problem. Suggestions on how to address this constraint are most
> welcome.

With an explicit main (i.e. a single explicit entry point to code).
Would also fix the "where can I initialize stuff" problem for good.

> However, it isn't a simple problem to fix.

With the current design, no. I personally use the following
idiom for an entry-point template with Werkzeug/GAE.

Think of `fw` as `django` in the following.

---

from fw.conf import settings

from . import settings as proj_settings

settings.register(proj_settings)

# all kinds of interesting explicit overrides
# and optimizations are possible now,
# just a random example that would
# be messy with current code
if settings.MIDDLEWARE_CLASSES:
from fw.core.handlers import MiddlewareHandler as Handler
else:
from fw.core.handlers import BaseHandler as Handler

from fw.webapp import run_wsgi_app

from .urls import url_map
handler = Handler(url_map)

def main(): # <-- the entry point
run_wsgi_app(handler) # or whatever

---

Disclaimer: I think that the Django way of doing things is
mostly fine and the effort to change the status quo is not
justified.