[Python-Dev] copy confusion (original) (raw)

Alex Martelli aleax at aleax.it
Tue Jan 11 23:56:26 CET 2005

On 2005 Jan 11, at 23:39, Phillip J. Eby wrote: ...

cls = type(x)

copier = copydispatch.get(cls) if copier: return copier(x) ... this a bug, or a feature of the revised copy/pickle design? Looks like a bug to me; it breaks the behavior of classic classes, since type(classicInstance) returns InstanceType.

It doesn't, because types.InstanceType is a key in _copy_dispatch and gets a function that implements old-style classe behavior.

However, it also looks like it might have been introduced to fix the possibility that calling 'copy' on a new-style class with a custom metaclass would result in ending up with an unbound method. (Similar to the "metaconfusion" issue being recently discussed for PEP 246.)

ISTM the way to fix both issues is to switch to using x.class in preference to type(x) to retrieve the copy method from, although this still allows for metaconfusion at higher metaclass levels.

What "both issues"? There's only one issue, it seems to me -- one of metaconfusion.

Besides, getattr(x.class, 'copy') would not give backwards compatibility if x is an old-style instance -- it would miss the per-instance x.copy if any. Fortunately, _copy_dispatch deals with that. So changing from type(x) to x.class seems useless.

Maybe we need a getclassattr to deal with this issue, since I gather from Armin's post that this problem has popped up other places besides here and PEP 246.

Apparently we do: a bug in a reference implementation in a draft PEP is one thing, one that lives so long in a key module of the standard library is quite another.

(Follow-up: Guido's checkin comment for the change suggests it was actually done as a performance enhancement while adding a related feature (copyreg integration), rather than as a fix for possible metaconfusion, even though it also has that effect.)

OK, but if Armin is correct about the code in the reference implementation of pep 246, and I think he is, this is still a bug in copy.py (though probably not the specific one that bit /f).

Alex

More information about the Python-Dev mailing list