On Friday, 23 October 2015 19:31:07 UTC+5:30, Marc Tamlyn wrote: > > This would cause too much churn for user code - there are millions of CBVs > in the wild with customised dispatch/get/post/etc methods which expect > these variables and perhaps use them directly. Unfortunately this ship has > sailed. > > Yeah I am also thinking that it is probably too late to make changes in CBGVs. But one this we certainly do is add request in args tuple in dispatch method. This way backward compatibility can be ensured pretty easily.
Currently many decorators have been written keeping these signatures in mind. Changing the whole signature will definitely break many of third party applications. I didn't get much time to try changing this signature, but I am pretty much certain about the destruction it will cause! > On 23 October 2015 at 14:45, Tom Christie <christ...@gmail.com > <javascript:>> wrote: > >> Although those variables are available in both places I'd prefer to see >> them passed explicitly. >> That will tend to nudge users slightly more towards passing variable >> around explicitly and slightly away from storing state on the view instance >> (which can be a bit of a gnarly practice - harder to follow the flow of >> where and when some piece of information is actually being used/modified) >> >> On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote: >>> >>> It looks like setting the request/args/kwargs attributes came after the >>> original CBGV implementation. >>> >>> https://github.com/django/django/commit/ea6b95db >>> https://code.djangoproject.com/ticket/19316 >>> >>> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion >>> >>> I haven't looked closely to see if your proposal might cause problems >>> (you could give it a try and see if you can get the Django test suite >>> passing), however, changing the signature of those methods would require a >>> deprecation path and could result in a lot of churn in user code which >>> would probably cause some angst. I'll leave it to users of CGGVs to offer >>> an opinion on whether or not it could be worthwhile. >>> >>> On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote: >>>> >>>> Hello all, >>>> >>>> With reference to this line: >>>> https://github.com/django/django/blob/master/django/views/generic/base.py#L61 >>>> >>>> from django.view.generic.base >>>> before calling self.dispatch request, args and kwargs attributes have >>>> been added to self. So these all are available in self in http_method >>>> handlers. >>>> >>>> I think this behaviour is present due to old functional views, but now >>>> passing these as arguments to http_method handlers look obsolete. >>>> >>>> We can potentially remove these and make http handlers more simple just >>>> like >>>> class CustomView(View): >>>> def get(self): >>>> request =self.request >>>> # code ... >>>> >>>> >>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > On Friday, 23 October 2015 19:31:07 UTC+5:30, Marc Tamlyn wrote: > > This would cause too much churn for user code - there are millions of CBVs > in the wild with customised dispatch/get/post/etc methods which expect > these variables and perhaps use them directly. Unfortunately this ship has > sailed. > > On 23 October 2015 at 14:45, Tom Christie <christ...@gmail.com > <javascript:>> wrote: > >> Although those variables are available in both places I'd prefer to see >> them passed explicitly. >> That will tend to nudge users slightly more towards passing variable >> around explicitly and slightly away from storing state on the view instance >> (which can be a bit of a gnarly practice - harder to follow the flow of >> where and when some piece of information is actually being used/modified) >> >> On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote: >>> >>> It looks like setting the request/args/kwargs attributes came after the >>> original CBGV implementation. >>> >>> https://github.com/django/django/commit/ea6b95db >>> https://code.djangoproject.com/ticket/19316 >>> >>> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion >>> >>> I haven't looked closely to see if your proposal might cause problems >>> (you could give it a try and see if you can get the Django test suite >>> passing), however, changing the signature of those methods would require a >>> deprecation path and could result in a lot of churn in user code which >>> would probably cause some angst. I'll leave it to users of CGGVs to offer >>> an opinion on whether or not it could be worthwhile. >>> >>> On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote: >>>> >>>> Hello all, >>>> >>>> With reference to this line: >>>> https://github.com/django/django/blob/master/django/views/generic/base.py#L61 >>>> >>>> from django.view.generic.base >>>> before calling self.dispatch request, args and kwargs attributes have >>>> been added to self. So these all are available in self in http_method >>>> handlers. >>>> >>>> I think this behaviour is present due to old functional views, but now >>>> passing these as arguments to http_method handlers look obsolete. >>>> >>>> We can potentially remove these and make http handlers more simple just >>>> like >>>> class CustomView(View): >>>> def get(self): >>>> request =self.request >>>> # code ... >>>> >>>> >>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a9c9e53c-091b-49b1-b737-833527189feb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
