HttpRequest.read(), HttpRequest.body, HttpRequest.raw_post_data

[Tom Christie]

I see that as of 1.4 `HttpRequest.raw_post_data` is being marked as "pending deprecation", and `HttpRequest.body` has been introduced.

This still leaves us with two ways to get at the request body - `.body` and `.read()`

If we're going to make the change of marking `raw_post_data` as deprecated,

wouldn't it make sense to only have a single interface to getting the request body,

rather than two different interfaces which behave in subtly different ways?

For example, we could also mark '.read()' as pending deprecation, and just have 'body' be a stream-like object.

I guess this'll fall into the "we can't do this now that we're in 1.4 beta" category,

but wanted to mention it because it won't really be viable to change the semantics of `.body` once 1.4 hits release,

and getting this right the first time around would be really nice.

Any thoughts?

  Tom

[Carl Meyer]

Hi Tom,

On 02/23/2012 06:07 AM, Tom Christie wrote:
> I see that as of 1.4 `HttpRequest.raw_post_data` is being marked as
> "pending deprecation", and `HttpRequest.body` has been introduced.
> This still leaves us with two ways to get at the request body - `.body`
> and `.read()`
>
> If we're going to make the change of marking `raw_post_data` as deprecated,
> wouldn't it make sense to only have a single interface to getting the
> request body,
> rather than two different interfaces which behave in subtly different ways?
>
> For example, we could also mark '.read()' as pending deprecation, and
> just have 'body' be a stream-like object.

Well, the reason .read() exists is because a design decision was made
long ago that HttpRequest objects should provide a file-like interface
(thus also .readline(), .readlines(), and .xreadlines()). Short of
reversing that decision (which isn't going to happen, given its long
history), deprecating .read() is not an option. And I wouldn't be in
favor of removing .body, which is the obvious HTTP-oriented name for the
request body.

I don't really see the presence of both as a problem. The "body"
attribute is the primary, and simplest, way to just get the full body of
the response. "read" is present only so that a request can be treated
like a file object.

Carl

[Tom Christie]

> a design decision was made long ago that HttpRequest objects should provide a file-like interface (thus also .readline(), .readlines(), and .xreadlines())

Wouldn't having .read() .readline(), .readlines(), and .xreadlines() all on `request.body` provide a slightly cleaner interface, whilst still staying in line with that design decision?

I might not normally be fussed about pushing for a core change like this, but it seems like if we're introducing `.body`, keeping things nice and tidy would be worthwhile.

[Carl Meyer]

On 02/23/2012 09:40 AM, Tom Christie wrote:
>> a design decision was made long ago that HttpRequest objects should
> provide a file-like interface (thus also .readline(), .readlines(), and
> .xreadlines())
>
> Wouldn't having .read() .readline(), .readlines(), and .xreadlines() all
> on `request.body` provide a slightly cleaner interface, whilst still
> staying in line with that design decision?

Maybe, maybe not. For simple cases, it's awfully nice that request.body
is just a string rather than a file-like object.

In any case, no point in arguing whether it's marginally better or not -
there's no way it's enough better to justify the massive
backwards-incompatible change for everyone currently using a request as
a file-like object.

Carl