Re: Are threading.local objects evil? (was Re: shortcut proposal)

2009-10-19 Thread Hanne Moa
On Fri, Oct 16, 2009 at 23:30, Michael P. Jung wrote: > Cal Henderson in the Keynote "Why I Hate Django" pointed out in a very > funny way that most projects never get THAT big that you need multi db > support, partitioning, extensive database clusters, etc. Just skip to >

Re: Are threading.local objects evil? (was Re: shortcut proposal)

2009-10-16 Thread Michael P. Jung
James Bennett wrote: > Setting aside async concerns, making the request available implicitly > would be both counter to that overall design (and I'm very much a fan > of that design, and I suspect its simplicity and understandability is > part of why Django's popular), and feels like an attempt

Re: Are threading.local objects evil? (was Re: shortcut proposal)

2009-10-16 Thread Michael P. Jung
Jeremy Dunck wrote: > 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. Untying the database session from the request response cycle makes sense for multi-db

Re: Are threading.local objects evil? (was Re: shortcut proposal)

2009-10-16 Thread James Bennett
On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung wrote: > So I wonder what would be wrong with putting the request object in a > threading.local object. It would neither kill performance nor cause a > poor architecture by itself. What's wrong, to me, is that it's a code smell

Re: Are threading.local objects evil? (was Re: shortcut proposal)

2009-10-16 Thread Jeremy Dunck
On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung 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

Are threading.local objects evil? (was Re: shortcut proposal)

2009-10-16 Thread Michael P. Jung
Hi Alex, 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