> 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.