Django-rest-framework: DRF `as_view()` uses `cls` to provide a reference to the view class, Django uses `view_class`.

[jieter]

Django rest framework uses cls and initkwargs to provide a reference to the class the view function originates from:

https://github.com/encode/django-rest-framework/blob/5521eacb024e8b477652a7c81eea88c941e0c322/rest_framework/viewsets.py#L126-L127

But django uses Django view_class and view_initkwargs:
https://github.com/django/django/blob/0315c18fe170b1b611b7d10b5dde2f196b89a7e0/django/views/generic/base.py#L72-L73

(added in commit a420f83e7d2e446ca01ef7c13d30c2ef3e975e5c, Django issue #24055.)

It would be nice if DRF and Django behave the same in this regard. Would you consider merging a patch changing DRF to use view_class/view_initkwargs?

[heemayl]

As both are attributes to the view function, it seems redundant to prefix them with view_ IMO.

[xordoquy]

That sounds reasonable to me. I'm not clear about whether it requires to follow the deprecation path or not.

[imomaliev]

Maybe this should be other way around. And django should be fixed instead?

[rpkilby]

I find it unlikely that this change would be accepted in Django. That said, if you do open a ticket for this, please link it here.

In regards to deprecation, I had previously implemented RenameAttributesBase for django-filter (which is based on Django's RenameMethodsBase), but it might need some polish.

[carltongibson]

If there’s a change on, we’ll do it here not in Django.

[imomaliev]

Hi, @carltongibson! I do understand that this naming works ok in django. And django should change it's API as less as possible. But shouldn't there be a process to rename something if it has some redundancy or wasn't chosen properly to begin with?

[carltongibson]

@imomaliev There is. It just doesn’t apply in this case. If this is to progress, it’ll be done here rather than in Django.

But we should make sure any changes properly follow the depreciation policy.

[tomchristie]

I think the downsides of changing this on our side probably outweigh the benefits. We'd likely end up breaking a bunch of user code as a result.