I've since moved the jaraco.functools project to Github, so here are updated links for those found in the original post to the [downstream bug](https://github.com/jaraco/jaraco.functools/issues/1) and the [offended code](https://github.com/jaraco/jaraco.functools/blob/56d1daf4b88239a137f03da87d312f2522df1078/jaraco/functools.py#L79-L145).

I've since realized, thanks to the test suite on jaraco.functools, a [follow-on issue](https://github.com/jaraco/jaraco.functools/issues/3) where it seems that if the deepcopy occurs on a wrapped partial, it will still fail, because the lru cache wrapper has no qualname:

$ cat > cache_copy.py
import copy
from functools import lru_cache, partial

foo = lru_cache()(partial(print, 'out'))
copy.deepcopy(foo)

$ python3.5 cache_copy.py
Traceback (most recent call last):
  File "cache_copy.py", line 5, in <module>
    copy.deepcopy(foo)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/copy.py", line 174, in deepcopy
    rv = reductor(4)
AttributeError: 'functools._lru_cache_wrapper' object has no attribute '__qualname__'

I realize now that when I reviewed the patch, I did not take the time to test it against my full use case, but only relied on the tests as committed, which did not cover this more nuanced usage.

On further consideration, this error highlights a potential subtle difference in the reduce support between the C implementation and the Python implementation.

In digging into the implementation, I don't yet fully understand how it is that the Python implementation survives a deepcopy, but I'd like to revisit this issue to see if it may be possible to make it so.