On Tue, Sep 18, 2012 at 7:24 PM, Cal Leeming [Simplicity Media Ltd] <cal.leem...@simplicitymedialtd.co.uk> wrote: > Russell, > > On a separate note, I am curious about these 'copy-on-call' leaks, and I > have not seen this behaviour documented anywhere else. > > "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)." > > Could you elaborate further on this, possibly with a rough example? > > Not arguing that CBV approach should be changed, but this copy-on-call > behaviour is quite unexpected, no?
The issue is the shallow copy. You create a view that sets up state in the __init__ method. Part of your view's state is held in a mutable object (e.g., a dict, list or object). The __call__ creates a shallow copy of the view object. A shallow copy of a mutable object copies the container, but the new container points to the old content. So, if your view logic modifies something held by the mutable object (which will be a fairly common occurrence), the modification will be shared by all instances of your view. Hilarity ensues :-) You could work around this by using a deep copy, but then you're into territory where accessing a view could be an incredibly expensive operation, which is something we want to avoid. It also means anything you attach to a view must be deep-copyable, which won't always be true. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
