> This would kill the ability to use __init__ to store anything on the
> instance, since it would only work for the first request, and so would
> enforce subclassing as the only means of customising behaviour. It would
> be more effective at dealing with thread safety concerns than a
> 'copy()', but breaking __init__() like that is fairly evil. I'm not sure
> if this is a serious suggestion or not...
if you remove the ability to set state in the constructor and rely
only in subclassing use __new__ instead of copy and all the thread
safety problems are solved.
Perhaps we could do something like that and provide a @classmethod in
View that easily subclasses a View with some default state, for
example:
views.py
------------
MyView(View):
...
urls.py
----------
url(r'^myview$', myapp.views.MyView, name='myview'),
url(r'^myview$', myapp.views.MyView.with_defaults(somevar=somevalue),
name='myview'),
--
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.
