permission instances instead of classes on views

[sparkyb]

I'm curious why views (and viewsets) have so many properties that expect a list of classes instead of a list of instances. In particular I'm wondering about permission_classes but renderer_classes, parser_classes, authentication_classes, throttle_classes, etc are all similar. The View has a get_permissions() method that is expected to return a list of permission instances, and so it calls the permission classes' constructors with no arguments. This requirement that permissions be implemented as a class whose constructor takes no arguments is very limiting to their reusability. To change the behavior of a permission you need to subclass it and write code or at least override class member variables. Another alternative I've seen is to have permissions refer to other properties on the view, but that only works if you're only ever going to use a single instance of the given permission class. It seems pointless and wasteful to have permissions use instance methods on an instance of a class that will have no instance variables (none of the built-in ones do).

It would be nice if I could have parameterized permission classes. For example, it would be nice if DjangoModelPermissions's constructor could take a list of permissions (or a map of permissions per action/method) so that I could customize which permissions to check for without having to write a subclass. Yes, I could write a class like this, but then I'd have to override get_permissions() in order to construct it with the desired arguments instead of being able to specify it as a class attribute.

What would be nice would be if I could specify permission instances instead of classes as a class attribute. I can think of a few ways to accomplish this and not break existing workflows. The simplest, but slightly hacky solution is to allow mixing of permissions instances in with classes in permission_classes. To do that, all you really need to do is give BasePermission a __call__ method that returns itself (making the attempted instantiation in get_permissions() a no-op) and also make it subclass from OperationHolderMixin (so instances can be composed the same way as classes. As an aside, if permissions instances were used instead of classes in the first place, it wouldn't have required a metaclass to make them composable). But it feels weird to put permission instances in an attributed named permission_classes. Better might be to have get_permissions() look for a permissions class member. If it exists, return it as-is, otherwise fall back on the current behavior of instantiating permission_classes. What do people think about this? Is there some reason for using all these lists of classes instead of instances that I'm not seeing?

[tomchristie]

I'm curious why views (and viewsets) have so many properties that expect a list of classes instead of a list of instances.

Well, because if they were instances, then it'd be much easier to accidentally use them incorrectly.

Setting state (eg. self.<something> = ...) would end up persisting across different requests.

Having them as classes means you end up with a fresh instance on each incoming request, which is what you want, really.

[sparkyb]

Ok, that makes sense, thank you. Then what is the preferred way of parameterizing them? Do you just have a lot of single-use subclasses with some class member overridden? Or is it common to create a class (or subclass) factory function so I can pass something to permission_classes that looks like a call to a parameterized permission class but is actually a call to a parameterized factory that creates a one-off subclass? Or is the most common case to just write a class that looks to some well-known member on the view for its parameter? I tend to use ViewSets with many extra actions so I'd either need to override this view member per-action in the @action decorator (which I guess I can, although that doesn't help if I have actions that cover several HTTP methods and want it to vary by that too), or I'd have to make the view member a dictionary that maps actions to values or something like that. Does that sound like the right approach?