[Tutor] How python keeps track of objects

[Mitch Raful]

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,))
    t0.start()
    t1 = Thread( target=get_files, args=(object, backup_dir))
   t1.start()

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:
>>      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
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20141123/7dc60583/attachment.html>