copy.deepcopy does not respect metaclasses with __deepcopy__ implementations

[4a02f6c7-c9b0-4553-b157-402311ed0fa5]

BPO	35410
Nosy	@elibixby
PRs	python/cpython#10903

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['3.8', 'type-bug', 'library'] title = 'copy.deepcopy does not respect metaclasses with __deepcopy__ implementations' updated_at = user = 'https://github.com/elibixby' ``` bugs.python.org fields: ```python activity = actor = 'elibixby' assignee = 'none' closed = False closed_date = None closer = None components = ['Library (Lib)'] creation = creator = 'elibixby' dependencies = [] files = [] hgrepos = [] issue_num = 35410 keywords = [] message_count = 1.0 messages = ['331073'] nosy_count = 1.0 nosy_names = ['elibixby'] pr_nums = ['10903'] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue35410' versions = ['Python 3.8'] ```

[4a02f6c7-c9b0-4553-b157-402311ed0fa5]

__deepcopy__ implementations on metaclasses are ignored because deepcopy explicitly ignores class objects.

It seems to me that more consistent behavior would be to use a null op as a fallback for class objects that do not have any of the relevant methods implemented (deepcopy, reduce, reduce_ex, etc)

I've attached a PR that implements this.

[iritkatriel]

Closing as the PR was abandoned by the OP. This can be reopened if someone wants to explain the use case and propose a patch with a unit test and documentation update.