Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#1321 closed task (fixed)

Modularised Django

Reported by: Armin Ronacher <armin.ronacher@…> Owned by: adrian
Component: Core (Other) Version:
Severity: major Keywords:
Cc: upadhyay@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


Django is the most ass kicking webframework ever created. So why not share knowledge and modules? There is a discussion on django-developers about split out the template engine and the ORM System.

I personally like the idea but how should this work?

  1. these module must not read DJANGO_SETTINGS_MODULE and other dependencies
  2. they shouldn't require a download of the whole django framework
  3. when used in django there shouldn't be too many (none) changes which might break backwards compatibility

The problem will be the last point in combination with the first two :-)

Attachments (2)

modularised_templates.diff (11.3 KB) - added by lukeplant 10 years ago.
Patch to begin implementation of this ticket
standalone-django.diff (13.2 KB) - added by Malcolm Tredinnick <malcolm@…> 9 years ago.
An updated version of Luke's patch that tries to work for all cases.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 10 years ago by upadhyay@…

  • Cc upadhyay@… added

comment:2 Changed 10 years ago by Fredrik Lundh <fredrik@…>

I can whip up a patch based on my proposal, in case anyone's interested (in brief: lazy access to the settings object/module, users may call django.template.setup before doing anything else if they don't want django's default setup).

comment:3 Changed 10 years ago by jacob

That sounds like a very good idea, Fredrik; a patch would be quite welcome.

comment:4 Changed 10 years ago by hugo

oh, please do that in the magic-removal branch, as that already has the refactored settings stuff.

comment:5 Changed 10 years ago by lukeplant

I paste binned this for Adrian's review during the sprint, but in case it gets lost I'm adding it here. It's a patch that gets the template part of Django modularised, and provides a bit of a basis for doing the rest. My notes are below, the patch is attached

The basic implementation is as below:
In django/template/ replace

  from django.conf import settings


  settings = LazySettings()

In django/template/*.py replace:

   from django.conf import settings


  from django.template import settings

Then there are a few bits and pieces that have to be changed to keep 'settings' from looking itself up in django.conf too early.

Some issues:

  1. Tests - I've added some, but because of DJANGO_SETTINGS_MODULE the test modules can't be imported into the existing test suite. Instead I've created a 'standalone' dir that contains test scripts that should just be run using system(), and a script '' that executes all the scripts in that dir.

  1. Default template settings: at the moment I've just duplicated the relevant parts of global_settings in django/template/ This obviously isn't OAOO, but I'm not sure how else to do it without ending up in all kinds of import loops or defeating the aim.
  1. The 'configure' method for template: maybe this should just have a list of explicit keyword arguments instead of having the TemplateSettings class.
  1. LazySettings - this bit is actually reusable for modularising other parts of the system. It might not want to live in datastructures though.

Changed 10 years ago by lukeplant

Patch to begin implementation of this ticket

Changed 9 years ago by Malcolm Tredinnick <malcolm@…>

An updated version of Luke's patch that tries to work for all cases.

comment:6 Changed 9 years ago by Malcolm Tredinnick <malcolm@…>

This latest patch uses Luke's ideas and tries to make them work for all Django subsystems. There is nothing specific about the templating system in there now. Documentation patches included, so usage should hopefully be clear. Can't test it yet as part of the automated test suite (still working on that), but running tests/othertests/ on its own will test these changes (it is forced to run in standalone mode).

comment:7 Changed 9 years ago by adrian

I'm looking at this patch...

Why is LazySettings.__setattr__() using this:

self.__dict__['_target'] = value

...instead of this?

self._target = value

comment:8 Changed 9 years ago by lukeplant

adrian: I think that originally came from me tying myself in knots trying not to trigger __getattr__ from __setattr__ in the case where you are trying to set the '_target' attribute. I think the method should look like this:

    def __setattr__(self, name, value): 
        if name == '_target':    
            setattr(self, '_target', value)
            setattr(self._target, name, value) 

comment:9 Changed 9 years ago by adrian

  • Resolution set to fixed
  • Status changed from new to closed

(In [2927]) Fixed #1321 -- Made DJANGO_SETTINGS_MODULE optional. You can now call django.conf.settings.configure() to set settings manually if you don't have a settings module. Thanks, Malcolm Tredinnick, Luke Plant, Fredrik Lundh

comment:10 Changed 9 years ago by adrian

Luke -- Ah, that explains it. I added a comment in the code in [2929].

comment:11 Changed 9 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top