Changed to Feature Request and added to PEP 42.

The docs (both the library ref and the comments at the top of copy.py) say that objects of class, method and function type are not handled by the module, so the docs match the code, and anything beyond that is a new-feature request.  Well, almost -- it's a bug that shallow copies *do* "work" for class type now (since the docs say it doesn't), but I'm not going to take that away now.

If/when copy/deepcopy are so extended, more is needed than the suggested patch:  after

y = deepcopy(x)

it should be the case that no mutations of x are visible via y, so _deepcopy_atomic is inadequate for anything with a writable attribute.  For example, after deepcopy'ing a class object, changing the __bases__ attr of the original should have no effect on the deepcopied clone.

So correct deepcopy implementations for these things probably need to use the "new" module.  I suspect the copy module punted on these types to begin with in part because "new" wasn't built by default in the past.