Question about references/copies

[Alex Martelli]

Arthur <ajsiegel at optonline.com> wrote:
   ...
> >If you know what type obj is, say a list; or, if don't really care
> >whether obj is (say) a list or a tuple or ... 'cause what you want is a
> >list anyway, then the normal way to spell this is of course list(obj).
> 
> Well there is a lot of divergence in practice, as I think you know.

Sure, I did say I've seen [x for x in thelist] used.

> And beyond that no real consensus on what is preferable, as far as I

Hmmm -- I've never seen a debate trying to determine that consensus,
actually.

> have been able to determnine  Though hearing Alex declare it as
> preferable is the beginning of the formation of some consensus, one
> hopes.

You're very kind, but I've hardly ever been able to convince GvR of
anything whatsoever;-)


> >> and/or that the copy module
> >> was something other than one of XXX importable moudles.
> >
> >Well, it's Python-coded, so it seems quite natural to me that it be a
> >perfectly normal importable module.
> 
> I understand, now, the problems with treating the copy module
> otherwise than it is.  But it is a strange duck - conceptually in the
> middle of things, but with limited functional importance. I thought

Yes, I see your point.  Anna and I just co-wrote a Cookbook recipe about
copying, so we ended up debating several such points and she also
brought this one up, btw

> only that Ray's idea of setting it off a bit, by mention in the
> tutorial, had considerable merit. 

Yep, I see that it might.

> I agree that dict(mydict) and list(mylist) -  it that is what one saw
> with consitentcy in practice - would go a long way. I'll try to
> practice it, having gotten into the list[:] habit.  

myseq[:] has the advantage of being polymorphic over list, tuple, str,
and array.array -- list(myseq) would produce a new list no matter what
the type of myseq (it's more polymorphic too, which is generally fine
but may perhaps hide problems if myseq is, say, a dict, unexpectedly
turning it into a sequence of its keys in arbitrary hash order).  I find
that when people are copying a dubious-type sequence they're often happy
with getting a list anyway (so they KNOW they can use list's wide
variety of methods), the only trouble case being indeed list(somedict).

> 
> And ...
> 
> It was my understanding - perhaps wrong - that dict.copy() was an
> add-on method to dict of non-ancient origin.  How do I check?

http://www.python.org/doc/versions.html

pointers to all versions of docs since 1.4 which came out in 1996.

to see that method copy was already in 1.5 (1998):

http://www.python.org/doc/1.5/lib/node13.html#SECTION0031600000000000000
00

I can't see it in 1.4 so I assume it was introduced between '96 and '98.

dict appeared in 2.2 (late 2001), see
http://www.python.org/doc/2.2/lib/built-in-funcs.html


> >> consider this entire area a significant wart. I think I am entitled to
> >> consider it so. 
> >
> >Given the apparent dearth of information in the matter, you may be
> >right.  I'll do my best to keep clarifying my viewpoint in my books...
> 
> That would be excellant!

Anna (my wife and coeditor), hearing from me a summary of this
discussion, decided (and easily convinced me) that copying needs to be
the first recipe in the book, and we have already written and committed
it, so, unless we get a veto from David Ascher, the other coeditor, or
from O'Reilly, that might help.  The recipe as it currently stands shows
copy.copy as the preferred way, with copy.deepcopy and calling the
object's type as secondary ways for particular needs, and L[:] as well
as [x for x in L] being specifically shown as wrong-headed approaches.
(We'll see how that survives tech review etc;-).


Alex