[Python-Dev] copy confusion

[Alex Martelli]

On 2005 Jan 11, at 23:39, Phillip J. Eby wrote:
    ...
>>     cls = type(x)
>>
>>     copier = _copy_dispatch.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 (copy_reg 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