On Feb 12, 2008 11:56 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Here's another way to look at it, maybe it'll help. My hunch is that > whenever someone writes x = copy(y), they actually know more about the > type of y than just that it is an object! Because if they knew > *nothing* about it, they wouldn't know whether copying was (a) > pointless (as it is for immutable objects), (b) impossible (e.g. for > sockets), or (c) useful (e.g. for lists). Based on the same reasoning, when we see x = copy(y) we can tentatively assume that y is a type that can usefully be copied. Unless we don't trust the author of the code to be sensible. > Seeing x=copy(y) provides no new information about y, since > all (well, most) objects can be copied. OTOH seeing x=y.copy() *does* > provide new information about y; it must be a type that has a .copy() > method. What useful information do we get by knowing that a type has a .copy() method? If I took the last sentence out of context, I would assume that having a .copy() method informs you that the type is copyable. Except you've just said that all (well, most) objects in Python can be copied--so I'm not sure new information a .copy() method conveys. Normally I might assume that it does a special kind of copying that doesn't fit the definition of copy.copy() nor copy.deepcopy(), except that for dict and set types, .copy() and .__copy__() are identical. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC
_______________________________________________ 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
