Hi,
first of all, I'd like to say that I fully agree that the final
solution has to be thread-safe and has to support storing state on
self.
On Oct 2, 12:32 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> 2010/10/2 Łukasz Rekucki <lreku...@gmail.com>:
> > Now you lost me. If we are discouraging people from using arguments to
> > __init__, why does the page list "You can't use arguments to init() to
> > instantiate a class view" as a drawback of the __new__ based approach
> > ?
>
> The difference is that __new__ doesn't *ever* allow for initialization
> arguments -- there is no way to pass an argument in. An "arguments
> disabled by default" __init__+copy implementation allows arguments as
> an opt-in.
Not 100% true. I suppose the main use-case of initialization arguments
is to have them in urlpatterns, right? You can still do that:
(r'^path$', 'MyView', {'option1': value1, 'option2': ...}),
The other use-case is to pass initialization arguments in your
views.py, but that can easily be replaced with subclassing:
class MyView(View):
option1 = value1
...
Indeed, this doesn't completely solve the problem of shared state
because value1 etc. will be shared, but neither does any of the other
solutions. However, with __new__ any *internal* state you store during
__init__ (e.g., self.state = [1, 2]) will be thread-safe (you can
later safely do self.state.append(3)) and that's IMHO an important
advantage over the __init__+copy() approach.
Independent of the approach, passing mutable arguments to __init__
isn't such a huge issue if you think of those mutable arguments as
*globally* constructed. Global mutable objects just aren't thread-safe
and that's one of the first things you have to learn when working with
multi-threaded code. So, even the __init__+copy() approach IMHO
doesn't make this problem really dramatic. After all, you're
constructing a *global* object. The default assumption is that it
"obviously" can't be thread-safe. To me, it's actually the other way
around: How the heck would I even know just by looking at a views.py
(i.e. without reading the documentation) that the *global* view
**instance** (!) is in fact thread-safe because it copies itself?
> There's also the wierd behavior that __new__ requires. Consider:
>
> x = MyView()
>
> What is x? If you use the __init__+copy approach, x is an instance of
> MyView. If you use __new__, x is a HttpResponse. It's a minor thing,
> to be sure, but this is a bit of a code smell to me.
I agree with Łukasz that this can be seen as a view factory. At least,
this is not much more magical than having non-obvious thread-safety
due to copy(). None of the solutions are perfect, but IMHO the thread-
safety advantages of the __new__ approach (i.e., internal state
created in __init__ is thread-safe) outweigh this minor detail because
bugs due to thread-safety issues are harder to track down.
Bye,
Waldemar Kornewald
--
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.
