Code

Changes between Version 7 and Version 8 of ClassBasedViews


Ignore:
Timestamp:
10/02/10 05:04:30 (4 years ago)
Author:
carljm
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.

Legend:

Unmodified
Added
Removed
Modified
  • ClassBasedViews

    v7 v8  
    3939 * Avoids messy and non-idiomatic hacks. 
    4040 * Avoids copying or creating new view instance on every request. 
    41  * 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. 
     41 * 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. 
    4242 
    4343Arguments against: 
     
    6666Arguments against: 
    6767 * 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. 
    68  * 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). 
     68 * 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). 
    6969 
    7070==== !__new!__() ====