Fails with Python 3.4

[chrisspen]

If I attempt to use requests with caching enabled in Python 3.4, I get this traceback:

    return requests.get(url).text
  File "/myproject/.tox/py34/lib/python3.4/site-packages/requests/api.py", line 70, in get
    return request('get', url, params=params, **kwargs)
  File "/myproject/.tox/py34/lib/python3.4/site-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/myproject/.tox/py34/lib/python3.4/site-packages/requests_cache/core.py", line 126, in request
    **kwargs
  File "/myproject/.tox/py34/lib/python3.4/site-packages/requests/sessions.py", line 488, in request
    resp = self.send(prep, **send_kwargs)
  File "/myproject/.tox/py34/lib/python3.4/site-packages/requests_cache/core.py", line 97, in send
    response, timestamp = self.cache.get_response_and_time(cache_key)
  File "/myproject/.tox/py34/lib/python3.4/site-packages/requests_cache/backends/base.py", line 70, in get_response_and_time
    if key not in self.responses:
  File "/myproject/.tox/py34/lib/python3.4/_collections_abc.py", line 428, in __contains__
    self[key]
  File "/myproject/.tox/py34/lib/python3.4/site-packages/requests_cache/backends/storage/dbdict.py", line 163, in __getitem__
    return pickle.loads(bytes(super(DbPickleDict, self).__getitem__(key)))
  File "/myproject/.tox/py34/lib/python3.4/site-packages/requests/packages/urllib3/packages/ordered_dict.py", line 8, in <module>
    from dummy_thread import get_ident as _get_ident
nose.proxy.ImportError: No module named 'dummy_thread'

As far as I can tell, dummy_thread is a Python 2.7 module, which doesn't exist in Python 3.*, so I'm not sure what would be trying to use it, much less for retrieving URLs.

[wong2]

+1

[ErinMorelli]

+1

[eloyfelix]

same problem here, using python 3.5

[jbrockmendel]

Seeing this in py3.5 and py3.6 using 0.4.13

[jbrockmendel]

Digging into this a little bit, the problem seems to be that the item being unpickled in py3 was pickled with py2. It looks like base.reduce_response is responsible for making sure the object being cached is pickleable. Is there anything in there that might be the culprit?

[seanwiseman]

+1

[brandonscript]

Are we going to get a new release that includes this fix?

[jhermann]

A better fix would be to catch pickle / any errors, log a warning (once?), and then perform the request as if the cache entry never existed. That'll auto-heal any incompatibilities, assuming you do not access the same store with different version combinations.

[brandonscript]

Yes, that would be much better!

[alex-stout]

Has this issue been fixed?

[chrisspen]

No. I've abandoned this package, as it appears unmaintained and doesn't support Python3.

[JWCook]

@chrisspen FYI, this issue has been fixed as of 0.5.2. Also, this package is being maintained again. The next release (0.6) will support only current python versions (3.6+); see issue #171.