On 10/02/2008, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Now, we have one and only one chance to slim-down the mapping API, leaving > the copy() > function as the one, universal, preferred way to do it. I don't think this > chance will come > again.
This discussion confused me (largely because of the subtle differences between the various ways of copying a dictionary). If I want a builtin dictionary from an arbitrary mapping d, I'd use dict(d.items()) - even if I knew d was a real dictionary. I wouldn't use d.copy() as that would not guarantee I had a builtin dict, should someone later pass me a user defined type. If I want a copy of an arbitrary mapping (or any object) and I want to preserve type, I would use copy.copy(). This is just as polymorphic as a copy method (interesting that it is Phillip arguing for methods being the polymorphic choice, when copy.copy is a generic function, which he has previously argued as being better...) I'm not sure how often I'd want to preserve type like this. It's never come up for me in real code. So I don't mind importing the copy module to get the functionality, it reminds me I'm doing something a little unusual. (On the other hand, (shallow) copy seems fundamental enough to me to qualify as a builtin, should someone care enough to argue for that). Given the above, I see no case where I'd want to use dict.copy(). So I'm in favour of removing it. On the other hand, I'd imagine it would be difficult to write a good fixer for this. I'm not sure how much of a showstopper that might be. Paul. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
