[Python-Dev] copy confusion

Phillip J. Eby pje at telecommunity.com
Tue Jan 11 23:39:34 CET 2005


At 11:20 PM 1/11/05 +0100, Fredrik Lundh wrote:
>I recently discovered that this feature has disappeared in 2.3 and 2.4.  in-
>stead of looking for an instance method, the code now looks at the object's
>type:
>
>     ...
>
>     cls = type(x)
>
>     copier = _copy_dispatch.get(cls)
>     if copier:
>         return copier(x)
>
>     copier = getattr(cls, "__copy__", None)
>     if copier:
>         return copier(x)
>
>     ...
>
>(copy.deepcopy still seems to be able to use __deepcopy__ hooks, though)
>
>is 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.

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.

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.

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



More information about the Python-Dev mailing list