On Sat, Oct 2, 2010 at 6:08 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: > On Fri, Oct 1, 2010 at 3:55 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >> On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: >>> On Oct 1, 11:16 am, Johannes Dollinger <emulb...@googlemail.com> >>> wrote: >>>> Could you (or anyone knowledgable) add a section, that explains why each >>>> request should have its own view instance? >>>> The thread-safety argument alone does not suffice: if all _request_ state >>>> would be stored on request instead of the view, you wouldn't need new >>>> instances per request. You could also pass around state explicitly - which >>>> admittedly gets messy quickly. >>>> So is this purely about preventing users from shooting themselves in the >>>> foot? (hyperbole: Will there be protection from globals in django 1.4?) >>> I think Johannes has a point. The copy-on-call may seem useful at >>> first sight, but as it's a shallow copy, it may perhaps engender a >>> false sense of security. So >>> >>> view_instance.attr = x >>> >>> will not result in threads stepping on each other's toes, but >>> >>> view_instance.container_attr.attr = x >>> >>> surely will? >>> >>> It seems better to stress thread-safety dos and don'ts in the >>> documentation. >> Without wanting to beat a dead horse, I concur. Fundamentally we need >> to have a little faith in your users, the admin has the exact same >> pattern of a single instance, and we haven't done anything special >> there. > > I second that view. We should tell people how to write thread-safe > code, not try to work around broken solutions. Thread-safe views are > easy. Just don't write to self once you're out of __init__. > Workarounds are not trivial, can make your life hard in wonderful ways > (like "why is __new__ called twice?") and intentionally break best > practices. I'd really prefer to teach people not to stab themselves > instead of forcing everyone to wear a shiny set of armor.
Opinion noted, but as I've said before, I fundamentally disagree. The argument here isn't whether it's easy to write a thread-safe view. It's whether you can accidentally write a thread unsafe view by following the practices you have used consistently in every other piece of code you have written. Python classes have state. People *will* assign variables to self, because that's something they have done with every other Python class in existence. And as soon as their code hits production, their code will break, in unpredictable ways. Claiming that users should RTFM/should know better isn't an acceptable excuse in this case, IMHO. When an API will break when you use it in the obvious way, that isn't something you can hide in documentation and say "we told you so". Yours, Russ Magee %-) -- 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.
