Allow rest_framework.request.Request instances #5724
Conversation
Instead of flat-out erroring (which can cause unhandled exceptions) let's perhaps be nicer to users who are considerately and carefully reusing ViewSets in other ViewSets. This means accessing the private attribute for them and then (and only then) raising an AssertionError if it isn't a Django HttpResponse instance. See also encode#5618
|
I'm definitely open to discussion, but my off the cuff reaction to this is -1. In general, request processing is complicated. Depending on setup, there are cases where the underlying Django request parses the incoming stream, and other cases where the DRF request object parses the stream. Processing the stream multiple times seems like it would be both inefficient and prone to error. As it currently stands, the assertion is a sanity check. |
|
I'm going to say No to this as is. I'm not 100% clear on the use-case. Something to do with re-use. I'm all for that but I suspect if you're bumping into errors here it's because you're not taking sufficient care over cloning the request before passing it off to another view. (I'm a wider point, my first approach would be to extract the (business) logic from the view such that I didn't need to leverage the whole request/response machinery in order to re-use it.) If there's a need to follow-up here I suggest a discussion on the mailing list to see if there's a work-around for a current use-case. If we can find a genuine limitation there then we can revisit as a new issue here. |
Instead of flat-out erroring (which can cause unhandled exceptions)
let's perhaps be nicer to users who are considerately and carefully
reusing ViewSets in other ViewSets. This means accessing the private
attribute for them and then (and only then) raising an AssertionError if
it isn't a Django HttpResponse instance.
See also #5618