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

Guido van Rossum gvanrossum at gmail.com
Tue Jan 11 23:58:08 CET 2005

[Fredrik]

>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 = copydispatch.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?

[Phillip]

Looks like a bug to me; it breaks the behavior of classic classes, since type(classicInstance) returns InstanceType.

I'm not so sure. I can't seem to break this for classic classes.

The only thing this intends to break, and then only for new-style classes, is the ability to have copy be an instance variable (whose value should be a callable without arguments) -- it must be a method on the class. This is the same thing that I've done for all built-in operations (add, getitem etc.).

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

Sorry, my head just exploded. :-(

I think I did this change (for all slots) to make the operations more efficient by avoiding dict lookups. It does have the desirable property of not confusing a class's attributes with its metaclass's attributes, but only as long as you use the operation's native syntax (e.g. x[y]) rather than the nominally "equivalent" method call (e.g. x.getitem(y)).

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list