[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.
--
DaveA
More information about the Tutor
mailing list