[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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
