On 25 elo, 23:22, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > In my opinion, option 2 is reasonable. I'm -0 on a stream_content keyword > argument for HttpResponse. I +1 on adding a separate HttpStreamingResponse > class, because it better reflects the difference in behavior, and because it > makes it possible to define a different API from the regular HttpResponse > (for instance, we can chose not to define response.content). Then we can use > a deprecation path to remove support for streaming responses in the regular > HttpResponse class.
I have been advocating for the stream_content approach simply because of possible problems in using HttpResponse subclasses in streaming situations. This is not a problem for me, as I usually have only HttpResponseForbidden and HttpResponseReverse in use, and those doesn't seem too useful with streaming content... However, if somebody has a heavily customized HttpResponse subclass in use, and needs to use it both in streaming and normal content situations, then that user might have some problems. Are there such uses for HttpResponse? There are more votes for the subclass approach. So, if no further opinions are raised lets go with that one. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.