An oddity in list comparison and element assignment

[Alex Martelli]

Slawomir Nowaczyk <slawomir.nowaczyk.847 at student.lu.se> wrote:

> On Sat, 03 Jun 2006 17:03:00 -0700
> aleax at mac.com (Alex Martelli) wrote:
> 
> #> Terry Reedy <tjreedy at udel.edu> wrote:
> #> 
> #> > Depends what one means by 'copy'.  See below for your alternate wording.
> #> 
> #> Please give me a reasonable definition of the unadorned word "copy"
> #> which would make this statement false.  (And, just to forestall one
> #> possible attempt: no, I cannot agree that a ``deepcopy'' is a reasonable
> #> definition of the _unadorned_ word "copy").
> 
> Actually, when *I* think about the word "copy", I have in mind what
> happens with files...

Sure!  In particular, to reproduce the concept of an object containing
references to other objects, imagine that the file is a .tar, .dmg (on
MacOSX), or other kind of "container"/"archive" kind of file, and one of
the items in its contents is a symbolic link.

When you copy the archive file, both the original and the copy now
contain symbolic links to the SAME target.

> and I to me semantics of []*3 is more like
> symbolic linking, not copying.

???  an _assignment_ in Python can be said to be "like symbolic linking,
not copying" -- and that's a crucial part of Python's semantics, of
course.  But the Sequence*N operation has nothing to do with creating
symbolic links; it may (of course) _copy_ such links, if they're present
in the sequence, just like copying a container file copies symbolic
links it may contain -- in each case one can end up with symbolic links
to the same target.  The analogy between files and Python objects is of
course not exact (partly because filesystems normally distinguish
between directories, which only contain references to files, and
"ordinary" files, that don't -- the Composite Design Pattern proceeds,
often fruitfully, by abstracting away this distinction), but in as far
as it holds, it points roughly in the right direction.  (GNU's cp offers
a -R switch to explicitly perform a "recursive copy", with other
switches such as -H, -L, -P to affect what happens in that case to
symlinks -- this -R is more akin to "deep copying", except that Python's
deepcopy is simpler, and always "recurses to the hilt").

> While I, personally, understand the
> sentence in question "The result of S*n or n*S is the concatenation of
> n copies of S" correctly, I *do* see how it might be misunderstood by
> others.
> 
> Not that I know how to express it better :-(

I do find it interesting that the concept of "copy" causes such trouble,
even when the analogies used (filecopying and symlinks) would tend to
point in the right direction.  The "real-life" analogy of copying a list
also points in the right direction: if I have a list of the writings I
hold on my library's top shelf, when I copy the list, both the original
and the copy point to _exactly the same_ writings -- not to separate
copies of each.  If I asked an employee to "please copy this list" I
would be astonished if he or she by default also copied each other
writing that is an _item_ on the list -- surely I would expect such huge
amounts of work to happen only when explicitly requested, and the
default meaning of "copy" to be therefore ``shallow'' (wherever
applicable, that is, when copying something that references other
things).  It would be interesting to study the root of the confusion in
more detail (although it's unlikely, as you indicate, that such study
would yield a different definition, concise and simple enough to be used
in a concise reference work, it would still help authors of tutorials).


Alex