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.

Reply via email to