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