Problem with objects copying each other in memory

andrew cooke andrew at acooke.org
Thu Feb 12 18:04:23 EST 2009


the official answer to that question is here -
http://docs.python.org/reference/datamodel.html?highlight=containers - at
about the 6th paragraph where it talks about "containers".

i think it's a hard question and really in a sense (imho) the real reason
is just that this tends to be the best compromise for the kind of language
that python is.

andrew


Cameron Pulsford wrote:
> Thanks, that did it! Why is that the case though? Or rather, why do
> the assignments to temp.x and temp.y not effect the self.x and self.y?
> How come I only run into the problem with the list?
>
>
> On Feb 12, 2009, at 5:15 PM, andrew cooke wrote:
>
>>
>> you're setting the new knight's "sl" to the value self.sl and then
>> adding
>> values to it.  that's the same list - so you are adding values to the
>> self.sl list when you add them to the knight's sl.
>>
>> this is easier to understand just by seeing the fix, which is to use:
>>
>> temp = Knight(self.x, self.y, self.g, self.h, self.gp, list(self.sl))
>>
>> which will make a new copy of the list, so you are only adding to
>> the sl
>> in the (new) knight.
>>
>> andrew
>>
>>
>>
>> dlocpuwons wrote:
>>> Using Python 2.6.1...
>>>
>>> I am (attempting) to make an A* search for a chess problem, but I am
>>> running into a really annoying shared memory issue in my successor
>>> function. Here it is stripped down to the important parts that relate
>>> to my problem.
>>>
>>> def successors(self):
>>> 		result = []
>>> 		moves = [[2, 1], [2, -1], [-2, 1], [-2, -1], [1, 2], [1, -2], [-1,
>>> 2], [-1, -2]] #possible moves for a knight
>>>
>>> 		for i in moves:
>>> 			temp = Knight(self.x, self.y, self.g, self.h, self.gp, self.sl)
>>> 			temp.x += i[0]
>>> 			temp.y += i[1]
>>> 			temp.sl.append([temp.x, temp.y]) #Adds the new current state to
>>> the
>>> visited states list
>>> 			result.append(temp)
>>> 		return result
>>>
>>> The method creates a temporary Knight object, increments it to the
>>> new
>>> position and then adds this new position to its list of visited
>>> states. Then it returns a list of these 8 new objects. The problem
>>> seems to be with the "result.sl.append()" line. As the method chugs
>>> along and creates the new objects the "temp.sl" lines seems to stay
>>> in
>>> memory, so when the method is done all the new objects have all the
>>> new states that were made over the course of the method instead of
>>> just their own created in the loop. For example when I try to get
>>> successors for a piece that is initially at (2,2) with no previously
>>> visited states, the method prints this out for the sl (state list)
>>> value
>>>
>>> [[2, 2], [4, 3], [4, 1], [0, 3], [0, 1], [3, 4], [3, 0], [1, 4], [1,
>>> 0]]
>>> [[2, 2], [4, 3], [4, 1], [0, 3], [0, 1], [3, 4], [3, 0], [1, 4], [1,
>>> 0]]
>>> [[2, 2], [4, 3], [4, 1], [0, 3], [0, 1], [3, 4], [3, 0], [1, 4], [1,
>>> 0]]
>>> [[2, 2], [4, 3], [4, 1], [0, 3], [0, 1], [3, 4], [3, 0], [1, 4], [1,
>>> 0]]
>>> [[2, 2], [4, 3], [4, 1], [0, 3], [0, 1], [3, 4], [3, 0], [1, 4], [1,
>>> 0]]
>>> [[2, 2], [4, 3], [4, 1], [0, 3], [0, 1], [3, 4], [3, 0], [1, 4], [1,
>>> 0]]
>>> [[2, 2], [4, 3], [4, 1], [0, 3], [0, 1], [3, 4], [3, 0], [1, 4], [1,
>>> 0]]
>>> [[2, 2], [4, 3], [4, 1], [0, 3], [0, 1], [3, 4], [3, 0], [1, 4], [1,
>>> 0]]
>>>
>>> but what it should print out is
>>>
>>> [[2, 2], [4, 3]]
>>> [[2, 2], [4, 1]]
>>> [[2, 2], [0, 3]]
>>> [[2, 2], [0, 1]]
>>> [[2, 2], [3, 4]]
>>> [[2, 2], [3, 0]]
>>> [[2, 2], [1, 4]]
>>> [[2, 2], [1, 0]]
>>>
>>> It sort of seems like python is trying to be too smart and is trying
>>> to keep things in memory. Is there anyway to work around this?
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>>>
>>>
>>
>>
>
>





More information about the Python-list mailing list