On Sep 27, 1:15 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > On top of that, there is the purely architectural argument: > threadlocals are a global variable by any other name. They increase > coupling in the systems in which they are used. If an engineer came to > you and proposed a design that relied upon the use of global > variables, they would be soundly ridiculed; but for some reason, > calling that same global variable a "threadlocal" makes it socially > acceptable. >
You're right in many ways, but these things are there because they're useful. You can't even get away from globals - every module is a global, and there's even a global list of them in sys.modules. Even the global settings in Django, which are the cause of a lot of pain, have been very useful in their way. It's definitely true that in the hands of the Wrong People, abuse of thread-locals could lead to maintainability nightmares. But that's not to say that there's no place for them anywhere; it's just that you have to provide very clear do's and dont's. This problem is not specific to thread-locals; an analogous case occurs in class-based views. There's no question (IMO) that class-based views can be a real boon, but they also need a warning label about not storing state in the class instance when processing requests. Interestingly, in the use case I mentioned, the use of thread-locals leads to a decrease of coupling in the sense that some third-party library knows nothing about the thread it's being called from or the request that it's helping to process, yet its logging messages can contain that context and thus be more useful. The alternative would perhaps be to e.g. pass a request from the view layer into the lower layers of code, which (a) would lead to increased coupling for no real benefit (methods which include the request in their signatures just so it can be reflected in log messages, for example), and (b) might not even be possible if you are using third-party code to do a decent chunk of your work for you (and that's code you can't easily control, and have no say in the design of). > It is entirely possible to build a robust, testable web system without > the use of threadlocals. You just need to be thorough in your design > work. > Modulo the use of third-party code, the design of which you generally don't have much influence over. By and large, I think we're in agreement: I just think that thread- locals have their place, but must be used with care and under the guidance of experienced practitioners. Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
