On Oct 2, 4:34 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> I can't argue with the fact that setting variables in __init__() is a
> common idiom in Python generally, and this is certainly a weakness of
> copy on call that will fail in non-thread safe ways.
>
> My counterclaim is that the move to class-based views is largely
> driven by a desire to discourage the use of arguments in this way. We
> want to discourage people from using arguments to class-based views,
> and use subclassing instead.
Talking about __init__ arguments is a red herring:
class Foo(View):
def __init__(self):
self.bar = []
self.baz = {}
I can't count the number of times I've done this; can you? This is an
outright failure mode for copy-on-call; no __init__ arguments are
involved.
(I was wrong in my earlier message; this can fail in single-threaded
development in consecutive requests. However, the failure is still
subtle, and depending on the details of what you're doing in the view,
may only manifest under certain circumstances. It still falls firmly
in the category of a confusing and non-explicit failure.)
> Lets be clear here - I don't particularly like *any* of the options on
> the table so far. However, my opinion is that copy on call is the
> option that will provide the least surprising behavior for the most
> common use cases -- having a subset of arguments to __init__ being
> unsafe is less surprising to me that having *all* attributes on self
> either unsafe, or actively prohibited.
It may be less surprising to you, but it's not at all clear to me that
you are representative of Django users in that :-) It is far more
surprising for me for such a low-level API to be making such odd fine-
grained distinctions about whether I can safely assign mutable or
immutable things to my instance in my __init__ method.
The issue is not only the frequency of failure, but how explicit/clear
it is. The failure here is so obscure and difficult to track down, it
is likely to generate an outsize support burden. In contrast, raising
an error on assigning to self can be completely explicit; no hours of
painful and confusing debugging necessary.
Let's also be clear to distinguish "just document that you don't store
state on self" vs "raise an error if you set an attribute on self."
These are proposals with very different characteristics in terms of
likely confusion and support burden.
> Agreed, there isn't much distinction. I suppose it's a matter of
> degrees. A simple "avoid lists and dicts as __init__ args" is an
> easier paragraph than something that tries to complicate matters by
> talking about readonly state and writable state, and mutable data an
> immutable data. The core of the matter isn't actually that different -
> it's just that you don't need all the extra framing complicating
> matters.
As soon as you try to explain to someone _why_ they can't store list
or dicts (or objects, such as QuerySets) as instance attributes in
self (again, whether it's an argument or not is irrelevant), you will
have no choice but to "complicate matters" by talking about mutable vs
immutable objects. By contrast, no such explanation is required if the
rule is "no attributes on self." The explanation there, even after
several levels of "why," is still a simple one-liner: a single view
instance is reused to serve multiple requests, so you can't put
request-specific stuff on it.
> We could even wrap the "no args to __init__" error check in a method
> that enables it to be overridden and silenced in a subclass; that way,
> introducing the potentially un-threadsafe behavior would need to be an
Again, arguments to __init__ are not the issue. What would have to be
checked is any assignment to self that takes place in __init__. How do
you propose to check that?
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.
