Scott David Daniels <[EMAIL PROTECTED]> wrote: > Ishwor wrote: > > On Thu, 23 Dec 2004 13:57:55 -0300, Batista, Facundo > > <[EMAIL PROTECTED]> wrote: > >>#- True, true. Maybe you could lobby for copy as a builtin in > >>#- Python 3000? > >> > >>That's a good idea to me. But copy() as a builtin is not clear if it's > >>shallow or deep. > > > > IMHO its preferable to use shallow one as the built-in because deep is > > expensive op. for CPU. ~;-) > "deepcopy" is an operation that is less well defined than shallow copy > anyway (and hence shouldn't be a default). Objects representing > constants may contain a cache (for example) as an efficiency measure, > and "deepcopy" needn't copy such objects. The only way to safely > do deepcopy is to copy down to immutables, but usually there is a > shallower and faster implementation that depends on application > semantics.
Well, that's what methods __copy__ and __deepcopy__, or the often-preferable __getstate__ and __setstate__, are all about -- letting your classes explicitly define what IS the state (that needs to be copied) of their instances. I don't see how that changes between copy/deepcopy being built-ins or being in a standard library module like today. Yes, deep copy is way more involved and expensive that shallow copy, etc, etc, but, again, this holds whether they're built-ins or come from a standard library module. I guess I must be missing something...? Alex -- http://mail.python.org/mailman/listinfo/python-list
