copy.deepcopy does not respect metaclasses with __deepcopy__ implementations

[elibixby]

BPO	35410
Nosy	@elibixby
PRs	copy and deepcopy functionality for metaclasses #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:

assignee = None
closed_at = None
created_at = <Date 2018-12-04.20:04:54.652>
labels = ['3.8', 'type-bug', 'library']
title = 'copy.deepcopy does not respect metaclasses with __deepcopy__ implementations'
updated_at = <Date 2018-12-04.20:04:54.652>
user = 'https://github.com/elibixby'

bugs.python.org fields:

activity = <Date 2018-12-04.20:04:54.652>
actor = 'elibixby'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2018-12-04.20:04:54.652>
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']

[elibixby]

__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.