Elegant copy-by-value

Mel Wilson mwilson at the-wire.com
Mon Jan 13 11:16:06 EST 2003


In article <x7ptr2rs1a.fsf at guru.mired.org>, Mike Meyer <mwm at mired.org> wrote:
>Martin Christensen <knightsofspamalot-factotum at gvdnet.dk> writes:
>
>> I wasn't thinking of simplicity implementation-wise. It just seems
>> very awkward to me that it should be necessary to import a module just
>> to be able to copy the value of even a primitive.
>
>If it still bothers you, how about a PEP proposing that object have
>copy and deepcopy methods that DTRT? That way, all new-style classes
>would have a copy and deepcopy methods, so you could invoke them
>without having to import a module.

   It seems to me that TRT for deepcopy is the
application-dependent feature from Hell.

   Say you have a dictionary of lists of class instances.
How does a dictionary deepcopy method distinguish between
list members that are shared-by-accident and those that are
shared-on-purpose?  Same for a list deepcopy method.
There's hope for a class deepcopy method, but even then you
might be requiring class instances to know what the
application was using them for.

   In a complicated case, any standard action will probably
include some amount of The Wrong Thing.  Best I think to let
the application programmer wrap up what needs doing
in a few appropriate custom classes.

   As somebody else said, copy and deepcopy aren't used
every day.  That seems a good argument for keeping them out
of the standard namespaces for the apps that aren't going to
use them.

        Regards.        Mel.




More information about the Python-list mailing list