[Python-Dev] Re: copy confusion

Fredrik Lundh fredrik at pythonware.com
Wed Jan 12 00:30:20 CET 2005


Guido van Rossum wrote:

> The only thing this intends to break /.../

it breaks classic C types:

>>> import cElementTree
>>> x = cElementTree.Element("tag")
>>> x
<Element 'tag' at 00B4BA30>
>>> x.__copy__
<built-in method __copy__ of Element object at 0x00B4BA30>
>>> x.__copy__()
<Element 'tag' at 00B4BA68>
>>> import copy
>>> y = copy.copy(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python24\lib\copy.py", line 93, in copy
    raise Error("un(shallow)copyable object of type %s" % cls)
copy.Error: un(shallow)copyable object of type <type 'Element'>
>>> dir(x)
['__copy__', '__deepcopy__', 'append', 'clear', 'find', 'findall', 'findtext',
'get', 'getchildren', 'getiterator', 'insert', 'items', 'keys', 'makeelement', 'set']
>>> dir(type(x))
['__class__', '__delattr__', '__delitem__', '__delslice__', '__doc__',
'__getattribute__', '__getitem__', '__getslice__', '__hash__', '__init__',
'__len__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__setitem__', '__setslice__', '__str__']

(and of course,  custom C types is the only case where I've ever used
__copy__; the default behavior has worked just fine for all other cases)

for cElementTree, I've worked around this with an ugly __reduce__ hack,
but that doesn't feel right...

</F> 





More information about the Python-Dev mailing list