On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung <mpj...@terreon.de> wrote: .... > mp> I've found it to be way more practical to just store the request object > mp> inside a threading.local object and let my functions access it directly. > mp> (...) > > Alex> Quite simply, no. Storing anything in a threadlocal instead of > Alex> passing it around is indicative of bad coding practice, and poor > Alex> architecture. > > Stating that the use of threading.local objects is "indicative of bad > coding practice, and poor architecture" is plainly wrong. > > I say: It depends.
Alex just spent a bunch of time adding multi-db support; part of the effort involved in that work was removing the request=thread=connection assumption that tied django to a single DB. So he's got a very specific viewpoint. I've previously advocated for something I'd call a blackboard-- a globally reachable place where middleware could scribble information, possibly useful to something else somewhere downstream in the system. This information would be safe to ignore if you weren't interested in this information. I think of it as a sort of persistent, opt-in signal. He reacted badly to that one, too. :-) But I'll side with Alex and say that a thread-local request is a bad idea. In fact, people do use Django in async systems: Old but useful here: http://code.google.com/p/django-on-twisted/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
