Requests 2.11.0 and Python 3.2

requests 2.11.0 is incompatible with python 3.2, but is installable:

```
# pip install requests
Collecting requests
  Downloading requests-2.11.0-py2.py3-none-any.whl (514kB)
    100% |████████████████████████████████| 516kB 1.4MB/s 
Installing collected packages: requests
Successfully installed requests-2.11.0
You are using pip version 7.1.2, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
# python --version
Python 3.2.6
```

This breaks dependencies for our clients. Could you please make it so 2.11.0 either works properly with python 3.2, or alternatively, make it so it is not installable in Python 3.2?


Hey @ppolewicz, I believe you can find answers addressing this in #3479, primarily @Lukasa's comment [here](https://github.com/kennethreitz/requests/issues/3479#issuecomment-238633044).

pip is currently unable to filter out libraries based on python version, but it was also [noted](https://github.com/kennethreitz/requests/issues/3479#issuecomment-238640627) in #3479 that this may be available in the _distant_ future. I'm not positive on when 3.2 was officially deprecated for Requests (it was before 2.11.0) but it was removed from the trove list in setup.py in May 2013. Unfortunately, I don't believe there's any intent to reintroduce support for 3.2, per @sigmavirus24 [comments](https://github.com/kennethreitz/requests/issues/3479#issuecomment-238640113).


I'm going to have to question the comments about 'This isn't possible to prevent installation' 

In `setup.py` if you have something along the lines of the following, `if sys.version_info not in [(2,6),(2,7),(3,3),(3,4),(3,5)]` than you could raise an error during `pip install requests` if the python version is outside one of the supported versions


If @Lukasa wants I'd be happy to create a PR for thisfor 2.11.1


## Tetra that does not work with universal wheels which is how most users will be experiencing requests installation these days. That only works for source distributions and we are not going to stop distributing wheels.

Sent from my Android device with K-9 Mail. Please excuse my brevity.


This is correct: right now the overwhelming majority of our users download wheels. A quick check of the PyPI download statistics reveals that for the 2.10.0 release last month, the wheel was downloaded 4,087,469 times, and the sdist was downloaded 364,911 times, making the wheels 11.2 times as popular a download as the sdist.

A solution that works only for the sdist is no solution at all.

I should note, as well, that adding a setup.py exception that prevents installation doesn't actually provide a useful behaviour. The _most_ useful behaviour would be if pip clamped the maximum version it would be willing to install on Python 3.2: e.g., if we could say "the last version that supported Python 3.2 was Requests 1.2.3, so go have fun with that". But that doesn't exist either.

I'm open to being told that there is a good way to handle this, but right now there just isn't.


Could we fix it in `2.11.1` by changing [those two lines](https://github.com/kennethreitz/requests/pull/3478/files) to use [six.u()](https://pythonhosted.org/six/#six.u)?
I understand that 3.2 is no longer supported by requests, but pip being broken as it is with the version mapping causes trouble for some people. Requests are extremely popular, so it is bound to break something somewhere. I think a minor change of 2 LOC to prevent this would be acceptable?


> I understand that 3.2 is no longer supported by requests, but pip being broken as it is with the version mapping causes trouble for some people.

I'm sorry, I don't quite understand what you are referring to @ppolewicz. 

> I think a minor change of 2 LOC to prevent this would be acceptable?

@ppolewicz except that minor change implies Python 3.2 support. Python 3.2 as a product itself is unsupported. The number of users it has according to PyPI is incredibly small. I don't see a whole lot of value in changing those two lines, but @Lukasa and @kennethreitz may disagree. I'm not against it, I just don't agree that we should be implicitly supporting an unsupported version that is mostly not used (regardless of how easy it is).


@ppolewicz In principle, yes, we could do that. In practice, doing so postpones the inevitable. You'll note that [pip itself dropped support for Python 3.2 in 8.0.0](https://pip.pypa.io/en/stable/news/#release-notes). People who refuse to upgrade to Python 3.3, which was released _four years ago_, are going to need to get comfortable with the idea that their software ecosystem is going to start breaking.

> Requests are extremely popular, so it is bound to break something somewhere. I think a minor change of 2 LOC to prevent this would be acceptable?

This logic is just fundamentally flawed. The same argument can be made to support Python 3.0 and Python 3.1, and Python 2.5 and earlier. Each change is only a few LoC, but at a certain point we're just holding ourselves back. 3.2 is no longer receiving security patches from Python dev, which means that it is no longer supported by Python-dev: it _should not be used anymore_, because it cannot be made to be secure.

I have exactly no interest in supporting Python 3.2 for free. Users who refuse to upgrade to Python 3.3 can apply patches themselves. Users who cannot upgrade to Python 3.3 because their LTS distribution will not ship it to them should contact their distributor, who can either apply appropriate patches themselves or who can pay the Requests development team to continue to support Python 3.2. Those are the two options I will find acceptable.


Fair enough.

Thank you for a detailed explanation.