[Python-Dev] copy confusion

[Guido van Rossum]

[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 = _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?

[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/)