[Tutor] How python keeps track of objects

Dave Angel davea at davea.name
Sun Nov 23 15:14:02 CET 2014

On 11/22/2014 09:28 PM, Mitch Raful wrote:
> If I have code similar to this:
> for object in objects:
>      do_something(object)
> def do_something(obj):
>       other_object = Class( obj.property)
>       other_object.method( arg1, arg2)
>      do_stuff here with other_object
>      if problem:
>           print( obj.property )
> My concern is that the for loop will wreak havoc with objects created in
> the function do_something.  Do I need to use Threading for the
> do_something?  Or does the interpreter keep track of all the
> 'other_object's as the for loop calls the function?

Welcome to Python-tutor.  I haven't seen you here, at least not lately, 
so welcome, and I hope we can be of some help.

Like Steven and Alan, I'm puzzled by your phrase "wreak havoc with 
objects".  But even more with your assumption that threading will help. 
  I have a hard time figuring out what your train of thought is.

Perhaps you read something somewhere that said "the way to solve (this) 
is by Threading..."  If you can quote the source, we can probably help 
you narrow down when it might apply.

More generically, threading is indicated in the following situations (it 
still isn't always the right answer):

1) You have a GUI, or other real-time requirement, and you have 
processing which needs to happen without impeding such requirement.  For 
example, you're doing a ten second calculation, but want the GUI to 
still respond to mouse clicks and such during the calculation.  The two 
approaches are a) break up the calculation into bite sized pieces, and 
return to the mainloop between the pieces for events to be processed. 
b) do the non-GUI portion in a thread, and resynchronize when it's done.

2) You need higher performance, and think threading will help.  If your 
code is doing a lot of I/O, then multithreading can frequently get some 
overlap with your computing.  But there are at least two other 
approaches here.  Multitasking can work better and easier, and can even 
help with help with CPU-bound tasks, if you have multiple cores.  The 
other obvious approach is non-blocking I/O.

3) You're learning, and want to study how threading works.

Note that correctness wasn't the excuse for any of these.  Generally, 
it's much easier to make a robust program with a single thread than with 
any multithreading or multitasking.

The other possibility that occurs to me is that you're worried about 
non-immutable objects in a list or other collection.  The list itself 
isn't an issue, it just means that your one name "objects" is bound to 
several objects rather than one.

When you pass a mutable object to a function, that function can choose 
to mutate it.  If you DON'T want that behavior, you can make a copy of 
the object and work on that copy.  For an example from the stdlib, 
compare list.sort() with sorted().

In your example, you printed obj.property.  If instead you had mutated 
it, the change would be observable in your original loop.  For example, 
you might say:

             if Found:
                 obj.count += 1

But if you do it deliberately, then you get what you wanted.


More information about the Tutor mailing list