Comment 1 for bug 1104370

Seriously - I'm sure no-one has *ever* tried this before. What I usually do is to call dict() on the attrib value, which is way more obvious and explicit and works just fine:

$ python -c 'import lxml.etree; print lxml.etree.fromstring("""<a b="foo" c="bar" />""").attrib'
{'c': 'bar', 'b': 'foo'}
$ python -c 'import lxml.etree; print dict(lxml.etree.fromstring("""<a b="foo" c="bar" />""").attrib)'
{'c': 'bar', 'b': 'foo'}

I'm not even sure what copy(Attrib) should return. It certainly can't return a new attrib proxy object, that wouldn't make sense at all.

For comparison, here's what CPython 3.4 gives me in a similar case, when requesting a copy of a dict items view:

>>> import copy
>>> copy.copy(dict(a=1, b=2).items())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python3.4-opt/lib/python3.4/copy.py", line 97, in copy
    return _reconstruct(x, rv, 0)
  File "/opt/python3.4-opt/lib/python3.4/copy.py", line 287, in _reconstruct
    y = callable(*args)
  File "/opt/python3.4-opt/lib/python3.4/copyreg.py", line 88, in __newobj__
    return cls.__new__(cls, *args)
TypeError: object.__new__(dict_items) is not safe, use dict_items.__new__()

Maybe mapping __copy__() to a call to dict() would be a reasonable compromise, just to keep it from failing...