Accept k/v lists in place of dicts everywhere.


Regarding Ordered Dicts (#284), if you're in need of a use case, [Amazon S3's Browser Uploads](http://aws.amazon.com/articles/1434) requires the form fields to be in a specific order. I just hacked up the code to use `collections.OrderedDict` where required to make this work. It looks like you're planning to do a bit more than that, but you're interested I can provide the modified code.


Actually, I'd like to do the opposite: turn incoming dicts (ordered or not) into `k, v` iterables, which will be parsed in order.


As this hasn't been done yet it would be nice to implement #507 as part of this implementation.


If no one objects, I might start hacking something together on this. Mainly I need it to [create a download](http://github3py.readthedocs.org/en/latest/repo.html#github3.repo.Repository.create_download) via the GitHub 
API using Amazon S3. But even by [creating a form reply](https://github.com/sigmavirus24/github3.py/blob/master/github3/repo.py#L293), this doesn't work (which leads me to believe I'm doing something else wrong).


@sigmavirus24 That'd be wonderful! Looking forward to it :)


I'll probably have time to work on it this weekend at the earliest.


So I started with `_encode_files` but realized that I cannot accurately test those changes since we seem to be having problems with the tests failing as the repository is now (at least they fail on my machine and I know @Lukasa is aware of this). Once those stop failing, I'll get back to work on this.


Hmm, I'll take a look.

Everything should be fine, according to Travis: http://travis-ci.org/#!/kennethreitz/requests

What errors are you seeing?


Scratch that. I had pulled but my directory had been dirty so after stashing I seem to not have pulled again. Sorry for the confusion. (Just pulled a second time to double check)


@sigmavirus24, hmm, what operating system are you running? what version of python?

can you try `make simple`


Oh, that's interesting. I remember what you're talking about @sigmavirus24 , but it's not the exact same failure case. The intermittent error I was seeing was associated with httpbin.org's /redirect loop occasionally returning 503s. [Relevant url](https://github.com/kennethreitz/requests/pull/746#issuecomment-7308242).

EDIT: too slow twice in a row. I'll leave this here for posterity.


Slackware 13.37 (x86_64) w/ python 2.6.6 but it was my error that the repository wasn't entirely up-to-date. I hope to finish `_encode_files` by the end of today to make sure it works properly. `_encode_data` already uses/accepts a list of k/v tuples and shouldn't really need to be changed unless I'm missing something.

Sorry to bother you @Lukasa.


It's never a bother. =)


Unfortunately I included my private email in a commit but whatever.

Can anyone point me towards other areas that require this? I would guess that the `params` keyword is already covered since both `data` and `params` use `_encode_params` which handles the list of k/v tuples use case.

Thanks for the pointers in advance.

Just to check, you also want: `headers`, `cookies`, `proxies`, `config`, and `cert` params in `Session.request` to accept a list of k/v tuples?


@kennethreitz Anything other than the following that need this functionality?

In `Session.request`:
- `headers` **done**
- `cookies`
- `proxies` **done**
- `config`
- `cert`
- `params` **done**


@sigmavirus24, `params`, `data` :)


Roger that. For some reason I thought `_encode_params` which takes `data` and `params` already handled this, but I'll double check in case I'm wrong. I'll hop to it later tonight.

**Edit**: `data` does, `params` does not.


"files" could benefit from the magic treatment too. Happy to chip in test cases & fix on top of @sigmavirus24 work if it helps.


@capped if you pull from git://github.com/sigmavirus24/requests and play around on fix_key_val_args branch it should work fine. Let me know if you run into any problems please. The changes are currently in PR #833 and now that you mention it, they should also close this issue entirely.


@kennethreitz I'm pretty sure you can close this. I'm almost entirely certain that this is resolved as per the last PR of mine you merged (the one in reference to #817)