[Tutor] How python keeps track of objects

[Mitch Raful]

On Sun, Nov 23, 2014 at 11:07 AM, Dave Angel <davea at davea.name> wrote:
> Please don't top-post.  Trim the quoted portion to the parts you're
> responding to, and put your response immediately after (each) section you're
> commenting on.
>
  I this the correct formatting and in plain text?

> Also, you're posting in html.  That's not always a problem, but it often is,
> depending on the vagaries of your email program.  Just tell it you want text
> format for your messages here, and we'll all see the same thing.
>
> On 11/23/2014 10:15 AM, Mitch Raful wrote:
>>
>> 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.
>
>
> I can't process that.  I don't know what you're asking.
>
  I think you actually answered this one.  Since the for loop has to
wait for the function to return, my 'other_object' can not get
clobbered.

>> Or do all languages keep each
>> call to a function in its own memory space and there is not a collision?.
>
>
> No such statement for "all languages," as there are tens of thousands of
> them, at least.  And certainly there are some that support implicit
> concurrency via something like  "for all" meaning "you may do all of these
> in parallel if you like, and I promise that order doesn't matter".
>
> In Python, however, the function as you had it in the original message
> returns to the for loop before it gets called again.  So there's only one
> instance of the stack frame.
>
> Three ways there can be multiple stack frames for the same function:
>
> 1) the function calls itself, directly or indirectly
> 2) you have multithreading
> 3) you have multiprocessing
>
> In all of these cases, the name other_object is unambiguously replicated in
> each instance of the stack frame.  And each version of that can be bound to
> an independent object.
>
>> 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.
>
>
> Then you are not just doing a simple function call.  You're doing some form
> of asynchronous I/O, either by threading, or by non-blocking I/O. In either
> case, your original example doesn't begin to represent what you're doing.
>
 Sorry for the newbie mistake of not mentioning that.

> The "responses come in" imply that somewhere you're polling for those
> responses.  Or you've changed your code to use multiple threads (as you show
> below).
>
>> 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.
>
>
> Once you launch a second thread, you have to worry about when it's done
> updating the corresponding item in objects.  So somewhere you probably want
> a wait() call.
>

 Would a t0.join() work instead of a wait call?

Mitch

> Anyway, the need for threads is triggered by my point 1), a need to continue
> your loop without waiting for the first operation to complete.  It doesn't
> happen to be the user interface that's causing it, but the network.  You've
> decided that you want to start multiple network operations without waiting
> for the first to complete.  That's easiest done with threads.
>
> --
> DaveA