instances v. threads

[Brad Tilley]

Rob Snyder wrote:
> Brad Tilley wrote:
> 
> 
>>I've just started using classes in Python for some projects at work and
>>have a few questions about them. I understand that once a class is
>>defined that I can create many instances of it like this:
>>
>>class xyz:
>>    def one():
>>       pass
>>    def two ():
>>       pass
>>    def three():
>>       pass
>>
>>a = xyz()
>>b = xyz()
>>c = xyz()
>>
>>a.one()
>>b.one()
>>c.one()
>>c.two()
>>c.three()
>>
>>How does asynchronous/threaded programming differ from OO programming
>>and classes? C is not OO and has no classes, but one can write threaded
>>programs in C, right? Perhaps I'm totally off on this... can some
>>explain how these concepts differ? Exactly how is an 'instance'
>>different from a 'thread'?
>>
>>Thanks,
>>Brad
> 
> 
> Heya Brad -
> 
> Looks like you're confusing two unrelated things. 
> 
> I'm not sure what you know about either thing, so forgive me if I am too
> basic in my attempt at explaining.
> 
> Take two simple Python statements:
> 
> a = "123"
> b = "456"
> 
> What have I? A variable named a that has the str data "123" in it, and one
> named B that has the str data "456" in it. Two variables (or "objects") set
> aside in memory, each storing a different value. You'd agree that the
> second line that sets the variable "b" does *not* create a new thread, or
> unit of execution, right?
> 
> Of course not. If this was my whole program, I'd have, effectively, one
> thread - the process itself, and two variables. 
> 
> Think of "instances" the same exact way. In your example above, the lines
> 
> 
>>a = xyz()
>>b = xyz()
>>c = xyz()
> 
> 
> create three new variables, each assigned to a new copy of your class xyz.
> When you call a method in xyz, such as a.one(), you are *not* creating a
> new thread. The program calls this method just as with any function, and
> when the function or method is done, it returns to your mainline code.
> 
> In other words, in your code example,
> 
> 
>>a.one()
>>b.one()
>>c.one()
>>c.two()
>>c.three()
> 
> 
> each of these executes *in turn*, not simultaneously. 
> 
> Now, suppose your class really looked like this:
> 
> class xyz:
>         def one(stuff):
>                 self.data = stuff
> 
> and I did
> 
> a = xyz()
> b = xyz()
> c = xyz()
> 
> then followed it up with
> 
> a.one("Hello, I am instance A!")
> 
> What is the value of a.data? "Hello, I am instance A!", of course. And the
> value of b.data and c.data? Not yet defined.
> 
> In my example, I have three instances of class xyz, and each has it's own
> private data. But that's it - each one does *not* create it's own thread;
> they do not execute asynchronously. 
> 
> If you're used to C programming, imagine classes as being similar to
> structs, just with the ability to include functions as well as data. 
> 
> Along the same lines, if I wanted to have multiple threads active, I'd have
> to create them, using any language that has a threading library (C does,
> Python does, Java does, etc.). I can certainly use classes and instances in
> my threads, but the two are not the similar concepts.
> 
> Make any sense?
> 
> Rob

Thanks Rob, that makes a lot of sense. I thought that instances ran 
simultaneously, not sequentially. Your explanation was right on... I 
understand how to think about instances now.