On Sun, Jan 30, 2011 at 2:20 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > Every single problem associated with using global variables exists > with threadlocals -- and then a few more. They *can* be used > successfully. However, in almost every case, they can also be avoided > entirely with a good dose of rigorous engineering. > > I *strongly* advise against the use of this technique. >
I understand (and completely support) your objection, specially when someone says «one could save even the request object to thread "global" and it would be accessible anywhere.» (which would make code using requests, i.e. a lot of it harder to reuse and to test) But the core problem being solved here, about moving SITE_ID to a threadlocal, doesn't look like bad engineering to me. In fact is moving something that is already global (everything in settings.py is) to alocation which is *less* global (thread-wise instead of process-wise). So this is an increase in locality, if I got it right... In which way is this worse than the current state of a global variable? (and in general, do you have some reference to explain «Every single problem associated with using global variables exists with threadlocals -- and then a few more»? I tend to think that a thread local is generally better than a global, even if it tends to be worse that good API design/argument passing) Regards, D. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
