Exception when preparing a request using a value from future.builtins str

Hi all,
I found an issue while passing data to requests which was wrapped in a call to `str(` imported with `from builtins import str` on python 2.7.13. 
The request fails to prepare with a KeyError. 
I tracked it down to here https://github.com/requests/requests/blob/master/requests/models.py#L104 where the value I'm passing in is being encoded. It is returning `bytes` and `urlencode` is choking on that. I tested changing 
`v.encode('utf-8') if isinstance(v, str) else v` to
`str(v.encode('utf-8')) if isinstance(v, str) else v`
and all tests passed while the issue I'm reporting is gone but I don't think that is the end of the story.

## Expected Result

I sort of expected it not to blow up. I'm using `from builtins import str` to deal with python 2 and 3 compatibliity issues and did not see this one comming.

## Actual Result

The `prepare` method raises an exception `KeyError: 98`

## Reproduction Steps

```python
from builtins import str
import requests
req = requests.Request('GET', 'http://httpbin.org/get')
req.params = {'email':str('bob@mail.com')}
req.prepare()
```
results in 
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "requests/models.py", line 259, in prepare
    hooks=self.hooks,
  File "requests/models.py", line 305, in prepare
    self.prepare_url(url, params)
  File "requests/models.py", line 423, in prepare_url
    enc_params = self._encode_params(params)
  File "requests/models.py", line 105, in _encode_params
    return urlencode(result, doseq=True)
  File "/usr/lib/python2.7/urllib.py", line 1349, in urlencode
    v = quote_plus(v)
  File "/usr/lib/python2.7/urllib.py", line 1306, in quote_plus
    return quote(s, safe)
  File "/usr/lib/python2.7/urllib.py", line 1299, in quote
    return ''.join(map(quoter, s))
KeyError: 98
```
## System Information

    $ python -m requests.help
```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": ""
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.13"
  }, 
  "platform": {
    "release": "4.10.0-38-generic", 
    "system": "Linux"
  }, 
  "pyOpenSSL": {
    "openssl_version": "", 
    "version": null
  }, 
  "requests": {
    "version": "2.18.4"
  }, 
  "system_ssl": {
    "version": "1000207f"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": false
}
```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).

I am confused. How does calling `str` deal with your Python 2/3 issues? Isn’t it just identical to using the naked string? Or are you using `from __future__ import unicode_literals`?

I suspect this is a Python 2/3 "compatibility" module the op is using that is doing something very weird/wrong.

I think they're using http://python-future.org/reference.html?highlight=str#past.builtins.strwhich has caused innumerable problems in the past around magically replacing imports in a quite terrible way.

I am certainly making that mistake and would be glad if you could enlighten me.
We had some `unicode(stuff)` on our code and was able to support python 3 by using 
`from builtins import str`
And changing that to `str(stuff)`, right until we hit this bump.
I read through some of the code in requests and I'm thinking I might just have to imitate what is done in the compat module.

@avilaton `six` is a significantly better library if you're trying to maintain compatibility on both Python 2 and Python 3.

I have no clue what `python-future` is trying to do in your code-sample, but you could more simply do `u'bob@mail.com'` That will ensure that it is text and will DTRT with Requests, etc. 

Fixed removing the usage of `from builtins import str` in favor of `from six import text_type`.
I read through the implementation of the former and there is clearly a lot of stuff in there I did not expect.
Closing, thanks for your advice @sigmavirus24 .

Just for the records, I had the same KeyError in _encode_params() in combination with python future.

 It was very strange. 

I was able to reproduce the exception in a test. 

The string which caused this issue was coming from `str(platform.uname())`. 

I could work-around this by using `repr(platform.uname())`.

In my case this was at the top of the file:

```
# -*- coding: utf-8 -*-
from __future__ import absolute_import, division, print_function, unicode_literals
from future import standard_library
standard_library.install_aliases()
from builtins import str
```

Just for the records, and to help other people who might have the same issue.

we use "from my_builtins import *" instead of the python-future now 

my_builtins looks like this

```
# -*- coding: utf-8 -*-
from __future__ import absolute_import, division, print_function, unicode_literals

# noinspection PyUnresolvedReferences
from builtins import *

str = unicode
```