Why passing request, *args, **kwargs in dispatch method for generic views

[Dheerendra Rathor]

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

[Tim Graham]

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.

[Tom Christie]

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)

[Marc Tamlyn]

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.

--
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.
To post to this group, send email to django-d...@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/6fe6b37d-8ab6-4c66-b036-db480547c4fd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dheerendra Rathor]

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!