requests[security] breaks on Python 2.6 after pyOpenSSL 18.0.0 (2018-05-16) drops support

WIth the 18.0.0 release, pyOpenSSL dropped support for Python 2.6.

As requests[security] pins pyOpenSSL with only a minimum version, fresh installations of requests pick up the latest and incompatible dependency.

## Expected Result

Requests[security] functions to work.

## Actual Result

```python
NameError: global name 'memoryview' is not defined
```

## Reproduction Steps

```python
>>> import requests
/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/cryptography/__init__.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. The next version of cryptography will drop support for Python 2.6
  DeprecationWarning
>>> requests.get('https://www.dwightgunning.com')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/requests/api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/requests/api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/requests/adapters.py", line 440, in send
    timeout=timeout
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/urllib3/connectionpool.py", line 601, in urlopen
    chunked=chunked)
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/urllib3/connectionpool.py", line 357, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/Users/dwight/.pyenv/versions/2.6.6/lib/python2.6/httplib.py", line 914, in request
    self._send_request(method, url, body, headers)
  File "/Users/dwight/.pyenv/versions/2.6.6/lib/python2.6/httplib.py", line 951, in _send_request
    self.endheaders()
  File "/Users/dwight/.pyenv/versions/2.6.6/lib/python2.6/httplib.py", line 908, in endheaders
    self._send_output()
  File "/Users/dwight/.pyenv/versions/2.6.6/lib/python2.6/httplib.py", line 780, in _send_output
    self.send(msg)
  File "/Users/dwight/.pyenv/versions/2.6.6/lib/python2.6/httplib.py", line 759, in send
    self.sock.sendall(str)
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/urllib3/contrib/pyopenssl.py", line 316, in sendall
    sent = self._send_until_done(data[total_sent:total_sent + SSL_WRITE_BLOCKSIZE])
  File "/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/urllib3/contrib/pyopenssl.py", line 304, in _send_until_done
    return self.connection.send(data)
  File "build/bdist.macosx-10.13-x86_64/egg/OpenSSL/SSL.py", line 1719, in send

NameError: global name 'memoryview' is not defined
```

## System Information

```bash
$ python --version
Python 2.6.6
$ python -m requests.help
/Users/dwight/.local/share/virtualenvs/stream-python-z8k7CN8K/lib/python2.6/site-packages/cryptography/__init__.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. The next version of cryptography will drop support for Python 2.6
  DeprecationWarning
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.1.4"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "2.6.6"
  },
  "platform": {
    "release": "17.5.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "100020ff",
    "version": "18.0.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": ""
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}
```


Hey @dwightgunning, thanks for bringing this to our attention! I think the easiest option is to pin a max version for Python 2.6 specifically in our `security` section of setup.py. Similar to how we handle `win_inet_pton`.

One thing we may want to consider is the implications of further supporting 2.6 as a “secure” option though. Given that it’s no longer (to my knowledge) receiving security updates and we’re pinning security packages at a possibly flawed point in time, do we want to reconsider dropping 2.6 prior to Requests 3.0.0?

/cc @Sigmavirus24

We haven't tested against Python 2.6 in a long time, @nateprewitt. In my mind, we dropped support for it a long time ago. Between pip dropping support for it, most packaging libraries dropping support for it, and our inability to test on Python 2.6, I think calling it unsupported in the next release is only reasonable.

Fair.

I setup a fork to test the fix proposed by @nateprewitt and works with my test application.

https://github.com/dwightgunning/requests/commits/v2.18.4-patched-for-py2.6

It's probably not really worthy of a PR but happy to raise one if you'd like to see it.

An alternative for anybody defining a package with setuptools is to use the `install_requires` property. For instance:

```python
install_requires = []
if sys.version_info < (2, 7, 0):
    install_requires.append('pyOpenSSL<18.0.0')

setup(
    # snip
    install_requires=install_requires
)
```



Also worth noting that urllib3 does still test against Python 2.6 and is using https://github.com/urllib3/urllib3/pull/1389 to fix this. I wonder if our "security" extra should just depend on the "secure" urllib3 extra and let that do that all the heavy lifting.

As for the alternative fix you've proposed @dwightgunning that only works if people are installing from an sdist. If anyone were to package a wheel for this, then they would not receive the right package version unless they capped it another way.

Python 2.6 was dropped by requests 3 in May 2017 (https://github.com/requests/requests/pull/4118).

Python 2.6 has been unsupported/EOL, and no longer receiving security updates (or any updates), from the core Python team since October 2013.

<img width=65% src=https://user-images.githubusercontent.com/1324225/40718094-78fb0814-6417-11e8-90d4-35e7343727a4.png>

https://en.wikipedia.org/wiki/CPython#Version_history

And there's relatively few pip installs on 2.6 for requests from PyPI (April 2018):

| python_version | percent | download_count |
| -------------- | ------: | -------------: |
| 2.7            |  64.02% |      4,941,921 |
| 3.6            |  21.76% |      1,679,455 |
| 3.5            |   8.29% |        639,898 |
| 3.4            |   5.38% |        415,136 |
| 2.6            |   0.28% |         21,280 |
| 3.7            |   0.16% |         12,724 |
| 3.3            |   0.11% |          8,204 |
| 3.2            |   0.01% |            808 |
| 3.8            |   0.00% |             52 |
| None           |   0.00% |             46 |
| Total          |         |      7,719,524 |

Source: `pypinfo --start-date 2018-04-01 --end-date 2018-04-30 --percent --markdown requests pyversion`

@hugovk 2.6 *and* 2.7 are planned to be unsupported with requests3. @nateprewitt already explained that.

Thank you for providing the download stats. I didn't know pypinfo did that. 

Hi again @hugovk, the plan is still to *remove* 2.6 (and in general python2) support in Requests3. The next release will simply be removing documentation that we support Python 2.6. I don't think there's a need to break existing implementations just because we don't support it anymore.

The statement of support for 2.6 in the current stable release was the reason I opened the issue. I understand it's annoying that the problem is introducing via an upstream change but I figured it's worth noting.

If there's a reasonable way to restore a "workable" py2.6 + Requests2 (even if the python version and some upstream deps aren't maintained) it'll probably be helpful to people.

Hi @dwightgunning, this is resolved in 2.19.0 which is now up on PyPI. We've also removed 2.6 references from the documentation, so going forward we'll be focusing on 2.7 for our Python 2 support target. Ideally Python 2.6 will continue working for the foreseeable future, but we won't be putting resources towards fixing future 2.6-specific issues.

Thanks again for letting us know about this!