Hi Tai, Thanks for your work and sorry for the late answer. I just had the time to review the discussion.
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. Once the deprecation path completes, I expect that: - HttpResponse will be simpler and more predictable (as it'll no longer contain code to support streaming) - both HttpResponse and HttpStreamingResponse will have intuitive and well-behaved APIs (which isn't true right now) - the implementations will be easier to understand and to maintain — HttpResponse was one of the hardest classes to port to Python 3, so much that I created a ticket saying it needs a refactoring. At a high level, I think this is a good compromise. It is fully backwards compatible for people that don't use streaming — the vast majority of Django users. It provides a robust foundation for the minority who does. It takes a bit more work than your current patch :) In addition, I'm -1 on encoding include or exclude filters in the MIDDLEWARE_CLASSES setting. Chains of includes and excludes are never a good idea — anyone who's struggled with a complex Apache configuration knows what I'm talking about! Best regards, -- Aymeric. -- 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.
