> Anybody have ideas on how to change the settings framework not to be > required at load time?
I'm not sure how acceptable this would be, but what springs to mind immediately is refactoring LazySettings and Settings to push all of the settings-loading logic into the Settings used, and using a Settings subclass by default that is happy to just use whatever the default settings are, and only raises an exception if you try to access a setting that's not in the defaults. Then in environments (like the various http handlers) that want to enforce the settings module being defined or configure() being executed, we can install a Settings instance in settings._target that behaves appropriately for those environments (eg, is thread-local and resets on request start in WSGI environments, for Paste friendliness). JP --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
