instances v. threads

[Brad Tilley]

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

[Rob Snyder]

Re: instances v. threads

Brad Tilley wrote:
[color=blue]
> 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[/color]

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
[color=blue]
> a = xyz()
> b = xyz()
> c = xyz()[/color]

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,
[color=blue]
> a.one()
> b.one()
> c.one()
> c.two()
> c.three()[/color]

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

[Scott David Daniels]

Re: instances v. threads

Rob Snyder wrote:
....[color=blue]
> Now, suppose your class really looked like this:
>
> class xyz:
> def one(stuff):
> self.data = stuff
>[/color]

Let's make this (as I'm sure you know):[color=blue]
> class xyz:
> def one(self, stuff):
> self.data = stuff[/color]

I just want to make sure newbies reading this doesn't get confused.

--Scott David Daniels
Scott.Daniels@A cm.Org

[Rob Snyder]

Re: instances v. threads

Scott David Daniels wrote:
[color=blue]
> Rob Snyder wrote:
> ...[color=green]
>> Now, suppose your class really looked like this:
>>
>> class xyz:
>> def one(stuff):
>> self.data = stuff
>>[/color]
>
> Let's make this (as I'm sure you know):[color=green]
> > class xyz:
> > def one(self, stuff):
> > self.data = stuff[/color]
>
> I just want to make sure newbies reading this doesn't get confused.
>
> --Scott David Daniels
> Scott.Daniels@A cm.Org[/color]

<smacks head> thanks Scott!

[Brad Tilley]

Re: instances v. threads

Rob Snyder wrote:[color=blue]
> Brad Tilley wrote:
>
>[color=green]
>>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[/color]
>
>
> 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
>
>[color=green]
>>a = xyz()
>>b = xyz()
>>c = xyz()[/color]
>
>
> 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,
>
>[color=green]
>>a.one()
>>b.one()
>>c.one()
>>c.two()
>>c.three()[/color]
>
>
> 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[/color]

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.