Tom Anderson wrote: > On Tue, 16 Aug 2005, Ron Adam wrote: > > >>Simon Brunning wrote: >> >> >>>On 8/14/05, Martijn Brouwer <[EMAIL PROTECTED]> wrote: >>> >>> >>>>I can imagine that *a lot* of libs/scripts use the copy library, >>> >>>I think that copy is very rarely used. I don't think I've ever imported it. >> >>I use copy.deepcopy() sometimes, and more often [:] with lists. >>Dictionary objects have a copy method. All non mutable objects are >>copies. > > > When you say [:], do you mean that you copy lists like this: > > l = someList() > m = [] > m[:] = l > > ? > > That's what i've been doing. The other day, i realised that i could just > do: > > l = someList() > m = list(l) > > The same works for copying dicts. Whilst it's still not utterly obvious > that what this is about is making a copy, it's more obvious, cleaner, > shorter and probably faster than the slice assignment, which is really > kludgy (almost intercalorific, in fact - or even perlish!). > Not really: it used to be the preferred mechanism, but now it seems a little old-fashioned is all.
> >>I too have wondered why copy isn't a builtin, > > > Same here. It seems like a sort of obvious thing to have, and could > probably implemented much more simply and quickly in the interpreter. > You'd probably want a __copy__ hook for classes which want special > handling, and just do a normal deep copy for everything else. > Well yes, but given that module copy now exists (and will therefore have to continue ti exist until Py3) that would introduce some redundancy. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list