2.3 list reverse() bug?

Bjorn Pettersen bjorn.pettersen at comcast.net
Fri Dec 26 05:28:42 EST 2003


Arthur <ajsiegel at optonline.com> wrote in
news:27umuvkmnbnk6qsdgbh7em35ekga1od1jv at 4ax.com: 

> On Thu, 25 Dec 2003 05:17:47 -0600, Bjorn Pettersen
> <bjorn.pettersen at comcast.net> wrote:
> 
> 
>> There is a module called copy that let you get the semantics that
>> you're looking for. I've never used it in my 6+ years of Python
>> programming, since it normally indicates the presence of flawed logic
>> <wink>. 
> 
> Why would you mention this in the context here?

Because it's true more times than not. People who believe they need a copy, 
usually comes from C++ where they've written copy constructors (ctors) as a 
matter of course to have their classes work with the std lib.

> I remain confused by this oft repeated mantra regrading the use of
> copy. Are  you saying that the need to copy a list indicates flawed
> logic, or that doing it otherwise than by list[:] is flawed?

Creating an exact copy by any means normally indicates to me that something  
is more complex than it needs to be. In object oriented terms, the concept 
of a copy doesn't really make sense. It's easier to see on a more concrete 
object, e.g. let me create an object representing my best friend:

  kira = Dog(breed='Akita', age=4, color='tri-colored')

what would a copy.copy(kira) be? Where would I use the copy without being 
able to use the original object?

The reason copy ctors are so frequent in C++ is simply because the language 
does not have garbage collection. There just isn't a convenient way of 
creating an object which outlives function scope yet doesn't leak memory.

There are of course times where a copy is needed (e.g. multi-version 
scenarios) but most programmers don't bump into these very frequently...

-- bjorn




More information about the Python-list mailing list