Just for completness: accidential assignment to the settings object itself
could be easily prevented with a __setattr__ method on its class, since
django yields on various other places about configuration problems it could
not be wrong if the programmer gets noted about an illegal assignment. If
everything works fine the method will only get called during startup, so
there is no runtime overhead. Simplified example:
def __setattr__(self, key, val):
if self.configured:
raise Exception('settings can not be changed after server startup')
super(LazySettings, self).__setattr__(key, val)
@Carl Meyer: At the first hand you're right, a thing all programmers should
know about (if they call themself so), but he assumed there existed some
kind of copy-on-read semantic for the settings, because you get something
different when imported from django.conf instead directly and because it's
a "magical" lazy object.
But since you all seem to like lists that much, maybe a compromise would be
to explicitly note in the docs that there is a danger in using lists which
can be prevented by tuple usage.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/ecb152a6-5478-45f1-89b9-3cfc0db27f30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
