Based on reviewing django code I'm tempted to consider "Only access api_settings inside running code, not inside class declarations." as a possibility. Note potential conflict of that approach with #2470.

My suggestion would be not to complicate things with reloading; since api_settings is a singleton object in the module, can you not change it to always look directly at django's settings, rather than copying them to USER_SETTINGS at import time? If you change
https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/settings.py#L186 to read val = settings.REST_FRAMEWORK[attr] you're halfway there.

We could although that wouldn't solve the class attributes that we set, such as APIView.renderer_classes. Those would still be evaluated at module import time.

Tom this PR is very helpful.

Going over the four options outlined - ordering them from worst to best in my opinion:

• "Automagically reload the required modules" - 👎 I think this would be horrible and agree it's not good.
• "api_settings.something returns a lazy object" ... Not sure if this is the Django way of building settings - could be confusing and long to implement.
• "Document the constraint, possibly adding a helper function..." - Basic solution and would be good, but won't work in all cases, such as where views are already loaded, as mentioned. Would help to alleviate some of the unexpected behaviour shock factor.
• "Only access api_settings inside running code, not inside class declarations" - 👍 for this. It seems the most Django-ish.

The 'runtime only' solution could probably be phased in over releases, and if there was documentation of the issue in the testing section of the site, this would create space for explaining which settings may not take effect when adjusted with override_settings.

Document now with helper and then work towards to 'runtime only' seems like a nice way to progress to me.

Document now with helper and then work towards to 'runtime only' seems like a nice way to progress to me.

@jamescooke Sounds sensible to me, yup! Esp the incremental approach.

👍

Is there a way to reload the DEFAULT_AUTHENTICATION_CLASSES and DEFAULT_PERMISSION_CLASSES when the view is defined as function with the @api_view['GET'] decorator?