On Feb 12, 2008 2:40 PM, Daniel Stutzbach <[EMAIL PROTECTED]> > 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.
My point is that (almost) any type is copyable so we can't tell what the author is assuming. Maybe they believe they had either a list or a dict -- or maybe they know they have an arbitrary class instance. > > 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? It rules out all classes that don't have one. That's nearly all types. > 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. Only dict and a few mapping-like types (and a vanishingly small number of user-defined classes) define copy(). > 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
