Many newbie questions regarding python
ethan at stoneleaf.us
Mon Oct 11 03:36:27 CEST 2010
Peter Pearson wrote:
> On Sat, 09 Oct 2010 19:30:16 -0700, Ethan Furman <ethan at stoneleaf.us> wrote:
>>Steven D'Aprano wrote:
>>>But that doesn't mean that the list comp is the general purpose solution.
>>>Consider the obvious use of the idiom:
>>>def func(arg, count):
>>> # Initialise the list.
>>> L = [arg for i in range(count)]
>>> # Do something with it.
>>> process(L, some_function)
>>>def process(L, f):
>>> # Do something with each element.
>>> for item in enumerate(L):
>>>Looks good, right? But it isn't, because it will suffer the exact same
>>>surprising behaviour if f modifies the items in place. Using a list comp
>>>doesn't save you if you don't know what the object is.
>>I've only been using Python for a couple years on a part-time basis, so
>>I am not aquainted with this obvious use -- could you give a more
>>concrete example? Also, I do not see what the list comp has to do with
>>the problem in process() -- the list has already been created at that
>>point, so how is it the list comp's fault?
> the unwary
> reader (including me, not too long ago) expects that
> L = [arg for i in range(count)]
> will be equivalent to
> L = [, , ]
> but it's not, because the three elements in the first L are three
> references to the *same* list. Observe:
My question is more along the lines of: a mutable object was passed in
to func()... what style of loop could be used to turn that one object
into /n/ distinct objects? A list comp won't do it, but neither will a
for loop, nor a while loop.
Further, Steven stated "it will suffer the exact same surprising
behaviour if f modifies the items in place" -- the damage has already
been done by that point, as L has however many copies of the *same* object.
Seems to me you would have to use copy.copy or copy.deepcopy to be safe
in such a circumstance, and the loop style is irrelevant.
If I've missed something, somebody please enlighten me.
More information about the Python-list