Hi Aymeric, Thanks for your reply. Actually I'm just using a memory cache for the response, so I'm not pickling it.
My thoughts are: 1. The __iter__ method of a HttpResponse should create an instance of a separate iterator class to iterate over the container. It should not return self. The iterator class instance can return self in it's own __iter__ method. This, I think, would get around the issue raised in https://code.djangoproject.com/ticket/13222. 2. I accept that StreamingHttpResponse instances can only be iterated once, and are therefore not suitable for caching. That's something that my application can handle. Do you think this would work OK? I'll create a ticket to track this. Thanks, Stephen On Tuesday, 2 April 2013 20:03:49 UTC+1, Aymeric Augustin wrote: > > On 25 mars 2013, at 18:02, SteveB <smbr...@gmail.com <javascript:>> > wrote: > > > I suspect this is a bug. Any thoughts? > > Yes, it's annoying, all the more since Django exposes response.content as > an attribute. > > > This works, but makes my code dependent on the internals of the > HttpResponse class, which isn't great. Any better ideas? > > I assume you're pickling the response to cache it. We could define a > __getstate__ method to remove _iterator from what's pickled, like this: > > def __getstate__(self): > state = self.__dict__.copy() > state.pop('_iterator', None) > return state > > Could you file a ticket so we don't lose track of this problem? > > -- > Aymeric. > > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
