Changes between Version 7 and Version 8 of ClassBasedViews

Timestamp:

Oct 2, 2010, 7:04:30 AM (14 years ago)

Author:

Carl Meyer

Comment:

self-correction: copy-on-call's failure can manifest in single-threaded dev, though only on subsequent requests, and perhaps not always even then.

ClassBasedViews

@@ -39 +39 @@
  * Avoids messy and non-idiomatic hacks.
  * Avoids copying or creating new view instance on every request.
- * All the options for actually protecting against thread-unsafety involve some kind of "surprising" behavior. The surprising behavior here (can't store state on self) is explicit and fails immediately, rather than failing mysteriously and only under concurrency.
+ * All the options for actually protecting against thread-unsafety involve some kind of "surprising" behavior. The surprising behavior here (can't store state on self) is explicit and fails immediately, rather than failing confusingly and only under certain circumstances.
 
 Arguments against:
@@ -66 +66 @@
 Arguments against:
  * The "copy on !__call!__()" approach is a little messy. Normal Python idiom wouldn't lead users to expect that !__call!__() would cause a copy to be created.
- * The abstraction of the copy-on-call can leak in surprising ways. Some users will try to set up state using an !__init!__ method (common practice). If any of the state they attach to self in !__init!__ is mutable (list, dict, object, etc) and they mutate it in the view, this is once again un-threadsafe (but will appear to work fine locally).
+ * The abstraction of the copy-on-call can leak in surprising ways. Some users will try to set up state using an !__init!__ method (common practice). If any of the state they attach to self in !__init!__ is mutable (list, dict, object, etc) and they mutate it in the view, this will fail (but not immediately, or in obvious ways).
 
 ==== !__new!__() ====