HttpResponse_is_string is removed Django 1.4

[Rajat Jain]

Hi,

I have noticed that the class variable HttpReponse._is_string (in django/http/__init__.py) is removed in Django 1.4. I was setting this variable in a couple of places in my code, so that piece of code is breaking in Django 1.4. Do you know if this field is required at all? If not, is it just safe to remove this field altogether from my code?

Thanks,

Rajat

[Rajat Jain]

[Ian Clelland]

On Thu, Apr 5, 2012 at 6:07 PM, Rajat Jain <raja...@gmail.com> wrote:

Hi,

I have noticed that the class variable HttpReponse._is_string (in django/http/__init__.py) is removed in Django 1.4. I was setting this variable in a couple of places in my code, so that piece of code is breaking in Django 1.4. Do you know if this field is required at all? If not, is it just safe to remove this field altogether from my code?

Were you setting it to True or False? 

If your code sets it to True, then this should be safe to remove -- in Django 1.4, HttpResponse always renders its output as a string, converts its contents to a string, regardless of what type of data it has been given.

If you were setting it to False, for some reason, then you'll have to come up with a different way of accomplish whatever you're trying to do.

(The original ticket was https://code.djangoproject.com/ticket/16494, and you can see the changes that were made for 1.4 here: https://code.djangoproject.com/changeset/16829)

 

--
Regards,
Ian Clelland
<clel...@gmail.com>

[Rajat Jain]

Thanks for the reply. Yeah I was just setting this to true.

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>

[Tom Evans]

FYI for the archives, if like me you were using this value to
determine if response.content was an iterator based response, then you
can simply invert your logic and use request._base_content_is_iter
rather than request._is_string.

The difference can be important if you are trying to cache an iterator
based response where the response must be iterated over and output in
chunks - the base cache middleware will naively try to slurp these
sorts of responses into a string.

Cheers

Tom