[Tutor] How python keeps track of objects
mitch.raful at gmail.com
Sun Nov 23 16:15:45 CET 2014
Thanks for the replies. My concern was as the for loop keeps sending
objects into the do_something() function which uses the same reference name
other_object and that the previously instantiated other_objected would be
mutated if the function wasn't finished. Or do all languages keep each
call to a function in its own memory space and there is not a collision?.
Since, in my case, do_something() actually occurs over a network and I use
the logging module, I noticed the responses come in whatever order they
have completed and not the order that do_something is called. I also have
another function that downloads the resulting files on the devices that
do_something() has them generate. To get all of this to look orderly in a
log output, I did this...
for object in objects:
t0 = Thread( target=do_something, args=(object,))
t1 = Thread( target=get_files, args=(object, backup_dir))
As to whether I read this somewhere, I wish I could blame a publication.
Alas, I came up with 'beauty' on my own.
On Sun, Nov 23, 2014 at 9:14 AM, Dave Angel <davea at davea.name> wrote:
> On 11/22/2014 09:28 PM, Mitch Raful wrote:
>> If I have code similar to this:
>> for object in objects:
>> 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.
> Tutor maillist - Tutor at python.org
> To unsubscribe or change subscription options:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tutor