On Oct 1, 10:00 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > Now, I'm sure the counterargument is going to be that copy() will be > just as error prone and FAQ inducing. My argument to this is:
Yes. > * when it fails, it will fail during development, not just in production > > * the cases where it will fail isn't the default usage case; it's > only going to be an issue when you have a deep data structure that you > are using in a mutable way. > > * the cases where it is even *potentially* a problem are an edge > case of common usage. None of these points seem accurate to me. The common failure mode for copy-on-call is someone setting self.foo to anything mutable (a list, dict, or object instance) in their __init__ method, and then later mutating it during the course of the view. Initializing state in __init__ to be modified by other methods is not an edge case, it's a common pattern of class usage in Python, almost as common as instance state itself. Likewise, mutable data structures (lists, dicts, objects) are not an edge case, but common Python idiom. And this failure will not fail quickly in development. It will work just fine in development, but will not be thread-safe, and will fail only under threaded concurrent load. > I'm a lot more comfortable with the idea of documenting "don't use > complex data structures as class arguments" than I am about > documenting "don't use self on a class". If nothing else, the > reasoning of "a copy is involved, so make __init__ arguments cheap to > copy" will give some protection. > Sure. Now try and explain what constitutes "mutable state" in a way > that makes sense to new Python converts. I don't see how you can get > into that sort of discussion without getting into deep copying, object > referencing, etc. I don't understand how these two paragraphs are internally consistent. I agree that explaining the intricacies of mutable vs immutable objects to beginners is impractical. So how then is it reasonable to document "you can set instance attributes in __init__ as long as they are immutable," which is what would have to be documented in the copy- on-call case? ISTM that of the thus-far proposed options for "preventing" un-thread- safe use of class-based views without changing the view contract, the only one that will fail fast in development is the proposal to make setting state on self raise an error or warning. Carl -- 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.
