I was going to propose the same thing Santiago. Signals seem like the ideal candidate to solve that problem. -- David Cramer http://www.davidcramer.net
On Fri, Nov 5, 2010 at 4:57 AM, Santiago Perez <[email protected]> wrote: >> * Settings that are internally cached. For example, anything that >> modifies INSTALLED_APPS. >> >> * Settings that need to make call to reset state affected by loading >> new new group of settings. For example, if you change TZ, you need to >> call "time.tzset()" on teardown to reset the timezone. Similarly for >> deactivating translations if you change USE_I18N. >> >> * Settings that need to be removed, rather that set to None. Again, >> TZ is an example here -- there is a difference between "TZ exists and >> is None" and "TZ doesn't exist". > > Isn't it be possible to change the setattr of settings so that when ever a > setting is changed, a signal is activated and those who cache or need to > trigger actions such as time.tzset() can hook to those signals to perform > those actions? If every setting is ready to be updated then a simple > decorator should be much simpler. These hooks could even allow the owner of > a setting to raise an exception when a setting is modified if it is truly > impossible to change it at run-time. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
