[New-bugs-announce] [issue31513] Document structure of memo dictionary to enable more advanced __deepcopy__ uses

Josh Rosenberg report at bugs.python.org
Mon Sep 18 16:05:46 EDT 2017

New submission from Josh Rosenberg:

At present, the documentation for the copy module doesn't document anything about the memo dictionary for deepcopy except to say that it must be received by custom __deepcopy__ methods and passed along when calling copy.deepcopy, and that it is a "dictionary of objects already copied during the current copying pass", without specifying what the keys or values are.

Without providing a documented meaning for the keys and values in the memo dict, it's impossible to use it in a supported way for more complex cases (e.g. a case where the object must be created partially and memoized prior to deepcopying attributes that can self-reference). For an example, see this StackOverflow answer's approach to using __deepcopy__: https://stackoverflow.com/a/46284091/364696

Officially, the line where it does:

memo[id(self)] = newself = self.__class__(copy.deepcopy(self.id, memo))

is not using documented behavior AFAICT; the fact that the memo dict maps id()'s of the original objects to the new instance is undocumented. This wouldn't be so bad if there were a documented way to achieve the desired result, but in recursive cases like these it's the only way to add deepcopy support without also adding pickle support.

I'd suggest documenting the current behavior, assuming the current behavior is consistent on all alternate Python implementations; I know id() is a little funky elsewhere, but I'm not sure there is any other sane implementation.

assignee: docs at python
components: Documentation
messages: 302485
nosy: docs at python, josh.r
priority: normal
severity: normal
status: open
title: Document structure of memo dictionary to enable more advanced __deepcopy__ uses

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list