renderer_classes decorator does not change rendering on view

[PaulWay]

Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

1. Create a viewset class that sets the renderer_classes property.
2. Import the renderer_classes decorator as renderer_classes_decorator.
3. Use it to decorate a view on the viewset.

Expected behavior

The decorated view should have a different set of renderer classes.

Actual behavior

The decorated view has the same set of renderer classes as the rest of the viewset.

[PaulWay]

From reading the code, I can understand that the renderer_classes decorator only works on view functions, and the renderer_classes property is meant to work across all the views in a viewset. So I'll understand if the response is "yes, it's supposed to work that way". In that case, what I'd recommend is putting in the documentation, and in the docstring of the renderer_classes decorator, that renderer classes can only be set on an entire viewset and not on a single view method in that viewset.

[rpkilby]

Hi @PaulWay. First, "yes, it's supposed to work that way" 😄.

I'd recommend is putting in the documentation,

Do you have any specific recommendations here? The API policy decorators section demonstrates that these decorators should be used with @api_view, and other documentation sections that (such as in the schema docs) show similar usage.

and in the docstring of the renderer_classes decorator

Adding a short blurb to the decorators might be helpful. e.g.,

def parser_classes(parser_classes):
    """Set the `parser_classes` for function-based API views."""
    ...

[xordoquy]

The documentation already states to use the class attribute:

You can also set the renderers used for an individual view, or viewset, using the APIView class-based views.

and only mention the decorator for the function based views.

[akx]

This is kind of unfortunate though – I have a viewset that has a default set of permission/throttling classes, which I'd need to override for a handful of @action() views.

I read the same documentation, but it also says "for an individual view", which led me to think things'd work with "individual views" such as @actioned ones within a viewset.

I'd suggest either

• implementing this support for @action views, or
• explicitly noting that these decorators will do nothing for @action views

[xordoquy]

@akx @action decorator creates a new class and takes most of the provided arguments as this new class attribute.
TL;DR, @action should already support renderer_classes attribute.
Note that the OP never mentioned the @action decorator so your comment is unrelated with OP's issue.

[akx]

@xordoquy Thanks! It seems @action(..., throttle_classes=[...]) works for my use case.

That does seem to be documented within the prose docs but not within the docstring (which is where I tend to look first since it's more easily at hand). Time for a PR to improve that...