Simplify Request()._encode_data()

The logic is the same. The only time we don't want to return 'data' is when it
isn't a file and can be iterated over.


This pull request [fails](http://travis-ci.org/kennethreitz/requests/builds/1628120) (merged 2e5dd3a1 into 08ac9897).


The failure is unrelated to the change as far as I can tell.


This pull request [fails](http://travis-ci.org/kennethreitz/requests/builds/1651099) (merged 0624b040 into 38db8c21).


The latter commit fixes what @lukasa noticed on #503


Hmm, wonder if i can get travisbot to trigger again.


This pull request [fails](http://travis-ci.org/kennethreitz/requests/builds/1669350) (merged 0624b040 into 38db8c21).


I wonder if merging what fixed the old tests will fix this pull request. Unfortunately my history is horribly ugly merging in usptream so if this passes you might cherry-pick the commits and I'll just forcibly rewrite my history.


This pull request [fails](http://travis-ci.org/kennethreitz/requests/builds/1669883) (merged e0274a65 into 64da351e).


The comment I deleted stands: I ran the tests on my machine with python 3000 and nose and got the same errors on my upstream branch as I get on my branch. I'll dig in to see if I can figure out where these tests are breaking.

**Update**: I tried running the tests individually, e.g.,

```
$ make simple  # nosetests tests/test_requests.py
$ nosetests tests/test_cookies.py
$ nosetests tests/test_requests_https.py
```

Only the last one passes with python3 on my machine on my branch tracking develop

**Update #2** After getting the tests working (thanks again @kennethreitz), I have a feeling the failure is related to nose and not requests or my changes. From what I can tell, the exception is occurring because of my having OpenDNS installed and running. This causes an error to be raised in the test for invalid content which causes the exception in nosetests. @jpellerin, @kumar303, any clues about the message above?


I disagree, the tests are legitimately failing. The four tests that are erroring out provide `data` as a string. In Python 3, strings implement the `__iter__` method. The same problem occurs with byte arrays in Python 3, which also implement `__iter__`. The tests will pass if you adjust your conditional to:

``` python
if hasattr(data, '__iter__') and not hasattr(data, 'read') and not isinstance(data, str) and not isinstance(data, bytes):
```

That said, the conditional becomes less nice in that form. I'm ok with having the `else` block all in one place, but I think this is about what PEP 20 suggests. I don't know which form fits PEP 20 better, and @kennethreitz has a better understanding of it than I do.


@Lukasa I was trying to find the bug using virtualenvs as well and couldn't get any better output than I described.

I'll take your word for it even though I don't understand why `not isinstance(data, str) and not isinstance(data, bytes)` would be necessary - neither has an `__iter__` attribute.

And yeah, if this is in fact the case, I'm all in favor of keeping it in the old style because that conditional would be horribly ugly. I just vastly dislike having so many return statements in one function.

Anyway, the other commit 0624b04 should still be considered since it's only a documentation change.

Sorry for the confusion


@sigmavirus24 Try opening a Python3 interpreter and typing the following:

``` python
a = 'test string'
hasattr(a, '__iter__')
```

It should return True. Strings and Bytes both have `__iter__` methods in Python 3, which is why your tests fail in Python 3. No need to apologise, I didn't know Python 3 strings had `__iter__` methods either, until I did my investigation.


Huh. When I was testing the hooks section the API wrapper I'm working on 
this morning, I thought I saw that this was passing on python 3 and 
failing on python 2. 

_shrug_. I'll close this and re-work my fork to only have the 
documentation change (and maybe one more that I promised @kennethreitz).

Thanks again for your help @Lukasa