Encode data according to Content-Type.

Hi,

It would be great that a request with a particular content-type would encode the "data" to the type given by the header Content-Type.


Don't mean to be blunt, but... this is out of scope. 


It's been heavily considered before, but it's definitely a step in the wrong direction.


Why? this will make my (and assume others) life really easy, If there
is already some decoding in the response with the content-type, why is
a wrong direction to do the same at the request?

By the first line on description: "Requests is an ISC Licensed HTTP
library, written in Python, _for human beings._", clearly stated that
this is a good direction.

On Mon, Dec 19, 2011 at 1:18 AM, Kenneth Reitz
reply@reply.github.com
wrote:

> It's been heavily considered before, but it's definitely a step in the wrong direction.
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/310#issuecomment-3199729

## 

Jorge Eduardo Cardona
jorgeecardona@gmail.com
jorgeecardona.blogspot.com

## github.com/jorgeecardona

Linux registered user  #391186

## Registered machine    #291871


What content types do you have in mind?

I'm assuming you mean json, etc.


Yeah, I'm thinking in json, xml, yaml.

On Mon, Dec 19, 2011 at 1:26 AM, Kenneth Reitz
reply@reply.github.com
wrote:

> What content types do you have in mind?
> 
> I'm assuming you mean json, etc.
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/310#issuecomment-3199760

## 

Jorge Eduardo Cardona
jorgeecardona@gmail.com
jorgeecardona.blogspot.com

## github.com/jorgeecardona

Linux registered user  #391186

## Registered machine    #291871


Yeah, out of scope. Requests is an HTTP module — not a json, xml, or yaml module. 

---

Don't worry, I absolutely understand the logic and the desire of this featureset, but it's simply not something requests is for.


But HTTP deals with content types, and that means json, xml, or yaml
in some cases, it can be an optional behavior too.

On Mon, Dec 19, 2011 at 1:36 AM, Kenneth Reitz
reply@reply.github.com
wrote:

> Yeah, out of scope. Requests is an HTTP module — not a json, xml, or yaml module.
> 
> ---
> 
> Don't worry, I absolutely understand the logic and the desire of this featureset, but it's simply not something requests is for.
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/310#issuecomment-3199827

## 

Jorge Eduardo Cardona
jorgeecardona@gmail.com
jorgeecardona.blogspot.com

## github.com/jorgeecardona

Linux registered user  #391186

## Registered machine    #291871


HTTP deals with bytes. 


Ok, but humans likes content types then, are you disagree even if this
is just an optional behavior? I don't think is too complex, I'll try
to add this and make a pull request if you agree to let it be an
optional behavior.

On Mon, Dec 19, 2011 at 1:44 AM, Kenneth Reitz
reply@reply.github.com
wrote:

> HTTP deals with bytes.
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/310#issuecomment-3199873

## 

Jorge Eduardo Cardona
jorgeecardona@gmail.com
jorgeecardona.blogspot.com

## github.com/jorgeecardona

Linux registered user  #391186

## Registered machine    #291871


I've heavily considered this in the past, and I can assure that it's not something that should be included in requests. 

Mind you — I don't think this is a bad idea. It just doesn't belong in requests. It could serve well as a separate module that you maintain.

---

Consider this: Okay, so you want to support JSON and YAML. What about XML? CSV? TSV? Where would you stop? The list of possible content types is limitless. The dependencies would continually grow. The (de)serialization standard aren't always uniform either.


I think a system where you could register deserialization handlers to content types would be ideal. By default Requests would just include a plain-text handler for everything and the end-user could register their own.


We can do as tastypie does, requests doesn't need to require all the
libraries for each content-type. If a particular content type is used
without the correct library it will raise an exception show in that.
In that way requests will not grow in dependencies, we can support the
basics json, yaml and xml, and if someone want more, a system as
@megaman821 says can help.

On Mon, Dec 19, 2011 at 8:48 AM, megaman821
reply@reply.github.com
wrote:

> I think a system where you could register deserialization handlers to content types would be ideal. By default Requests would just include a plain-text handler for everything and the end-user could register their own.
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/310#issuecomment-3203260

## 

Jorge Eduardo Cardona
jorgeecardona@gmail.com
jorgeecardona.blogspot.com

## github.com/jorgeecardona

Linux registered user  #391186

## Registered machine    #291871


This is never going to happen. Requests is an HTTP module, not an xml, json, yaml, etc module. 

I would be very excited to see someone build a complimentary module that provides this functionality, but it does _not_ belong within requests itself.


I'm sorry if it seems like I'm being difficult — I'm usually quite receptive of ideas like this.

I've been down this road dozens of times myself, and have already determined that it's the wrong direction.


I would agree with not including json, xml, etc., just providing the hooks for an interested party to do it themselves. The only handler Requests should include is the plain-text handler which goes mirrors what Request already does.


Requests currently provides plain text and unicode.

I wouldn't be against a pipeline that someone could hook into for doing this, actually. Sounds like an interesting idea. What would it look like?


This will do the trick with json:

```
def encode_content_type(args):
    " Encode the data using the 'Content-Type' header."

    if 'Content-Type' not in args['headers']:
        return args

    if args['headers']['Content-Type'] == 'application/json':
        args['data'] = simplejson.dumps(args['data'])

    return args
```

Now, the hook has to be passed to the get/post/put/delete method, is
there a way to register a hook without passing it to every request in
the hooks dict?

On Mon, Dec 19, 2011 at 3:12 PM, Jorge Cardona jorgeecardona@gmail.com wrote:

> Actually, it can be done using the "args" hook.
> 
> On Mon, Dec 19, 2011 at 12:53 PM, Kenneth Reitz
> reply@reply.github.com
> wrote:
> 
> > Requests currently provides plain text and unicode.
> > 
> > I wouldn't be against a pipeline that someone could hook into for doing this, actually. Sounds like an interesting idea. What would it look like?
> > 
> > ---
> > 
> > Reply to this email directly or view it on GitHub:
> > https://github.com/kennethreitz/requests/issues/310#issuecomment-3206717
> 
> ## 
> 
> Jorge Eduardo Cardona
> jorgeecardona@gmail.com
> jorgeecardona.blogspot.com
> 
> ## github.com/jorgeecardona
> 
> Linux registered user  #391186
> 
> ## Registered machine    #291871

## 

Jorge Eduardo Cardona
jorgeecardona@gmail.com
jorgeecardona.blogspot.com

## github.com/jorgeecardona

Linux registered user  #391186

## Registered machine    #291871


Add it to the session.