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. -- Patryk Zawadzki -- 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.
