Incompatibility with Python 3.1

requests/models.py and tests/test_requests.py recently started using callable(), which is not available in Python 3.1.

```
$ python3.1 tests/test_requests.py -v
...
======================================================================
ERROR: test_allow_list_of_hooks_to_register_hook (__main__.RequestsTestSuite)
Issue 785: https://github.com/kennethreitz/requests/issues/785
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_requests.py", line 776, in test_allow_list_of_hooks_to_register_hook
    assert_hooks_are_callable(r.hooks)
  File "tests/test_requests.py", line 771, in assert_hooks_are_callable
    assert callable(h) is True
NameError: global name 'callable' is not defined

----------------------------------------------------------------------
Ran 76 tests in 64.134s

FAILED (errors=1)
```


`callable()` is back starting from Python 3.2 so just move forward :)


Wow, they removed callable?


Yeah, seems they did. This is just ridiculous. Is there a better way to test this? 


When callable() does not exist, then you can use `hasattr(x, "__call__")` or `isinstance(x, collections.Callable)`. (The second way is better.)


+1 for `collections.Callable`


That's guaranteed across all versions of python that requests supports, right? 


You can use:

```
import collections
try:
    callable = callable
except NameError:
    def callable(x):
        return isinstance(x, collections.Callable)
```


Meh, it would be easier to just use the isinstance pattern everywhere. 


Yeah, I see no need to split.


> I see no need to split.

I don't quite catch what you mean @kennethreitz 


@kennethreitz: Do we want to fix this, or just stop claiming that we support Python 3.1, seeing as we don't test on it anyway?


I want to officially support 3.3 and up. Anything else is nice-to-have :)


Right. In that case, I'll run the tests on my box in Python 3.1 and see how much work is required to get them passing again.


There's no way as far as I can tell to make Travis test 3.1 at the moment. http://about.travis-ci.org/docs/user/ci-environment/#Python-versions Also they still don't have support for 3.3 (unless their docs are wildly out of date).


It's undocumented, but exists if you specify it. They are working to remove it though.

We had a big argument about it this week :)


Well in that case, perhaps removing the guarantee of 3.1 compatibility is the way to go. It would seem @Lukasa nipped this in #955 though, so this should be fixed. @Arfrever care to confirm?


I agree.


I think that the set of supported versions of Python should not be restricted by what is supported by Travis.


@Arfrever there's this from Kenneth:

> I want to officially support 3.3 and up. Anything else is nice-to-have :)

But the other issue is that automating (regression) tests for python 3.1 is a pain. If someone wants to volunteer a server, they can use any of the GitHub API wrappers to verify the tests work on 3.1 and post as much.


Travis is just a nice excuse to not support it.

I came up with the idea for the unicode literals PEP, actually, and it was for Requests. I have full intentions to use it.


There might be software projects, which use Requests, but do not yet work with Python 3.3, so please do not remove support for Python 3.2.

AFAIK the only feature present in Python 2.6, 2.7 and 3.2, but not in 3.1, is callable(), which can be easily defined for Python 3.1 as shown in comment 9202340.


@Arfrever: Such a project can continue to use Requests 0.14.2 (or whatever version we get to where we finally break 3.2) with no ill effects.

Regarding supported versions, if Travis doesn't test 3.1 for us then we have to assume that anyone raising a PR has not tested on 3.1 either. This requires Kenneth (or another contributor) to patch a copy of Requests with the PR and test it themselves, which is boring and time-inefficient. It's for this reason that bugs like this one crop up in the library: we simply do not have time to catch regressions.

If I thought supporting 3.1 and 3.2 was a long-term priority I'd try to use a local box to run these tests automatically, but the reality is we're simply going to stop supporting these versions. To be clear, we aren't going to break these _right now_: I'm not going to raise a PR tomorrow that puts unicode literals on every string, for instance. 3.1 and 3.2 will likely continue to function until 1.0, when Kenneth finishes his Transport Adapters stuff.

In the meantime, the original issue is fixed, so I'm closing it. Thanks for the bug report, please keep them coming! =)


@Lukasa well explained. Thank you.