I'm working on a patch (actually I use it for about a week locally) that allows one to put an iterator as a content for HttpResponse. This is intended primarily for large file-like objects that are fed to the user incrementally without reading entirely into memory. This also allows to invent some fancy iterators for output. I use one to constrain output bandwidth for example...
To finalize the thing I need some comments about design of HttpResponse. Currently HttpResponse looks a bit strange. It has 3 ways of accessing its content: - get_content_as_string(charset) -- checks if content is unicode and converts it to charset - __str__ -- concatenates content with headers but doesn't check for unicode and doesn't convert - raw attribute content I did find that "get_content_as_string" and "content" both used. Didn't find any explicit str(response) but it may be done implicitly anywhere. My current design is as follows: - HttpResponse is converted to a new style class - content becomes a property and is the only interface to the content - on getting content HttpResponse checks for unicode and converts it to DEFAULT_CHARSET - get_content_as_string(charset) goes away, the only place where it is used with non-default charset is a cache middleware that asks it in utf-8. But it's still can be not utf-8 and cache middleware shouldn't care anyway, all it wants actually is a byte-string, not certain charset - __str__ will concatenate headers with content - HttpResponse gets an attribute "stream" which is an iterator over content. In the case of file response it's the file-like object and in case of a string it's a list with single string. This is the iterator that WSGI wants, BTW. - HttpResponse.write raises an exception when HttpResponse was created with an iterator and not a string. If it's a string it appends to it. Any thoughts? --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
