On threads and constructors

Peter Hansen peter at engcorp.com
Fri Dec 30 22:10:54 EST 2005


techiepundit at futurepundit.com wrote:
> I have a class:
> 
> class ServerThreadManager(threading.Thread):
>     def __init__(self):
>         threading.Thread.__init__(self)
>         # and a bunch of constructor statements
> 
>     def run(self):
>         self.ReqHandlingLoop()
> 
>     # and a bunch of other methods
> 
> ServerObj = ServerThreadManager()
> print "starting ServerThreadManager"
> ServerObj.start()
> 
> ServerObj.KeyboardWatcherLoop()
> 
> Here's what I want to know:
> 
> 1) In __init__ I added that other __init__ call from a post here or
> from an article on a web page. Does that make sense to do? Why is it
> necessary? Do parent constructors always run in Python? If so, before
> or after child constructors?

Think of them as "initializers" rather than constructors, since the 
object is already created by the time they are called.  In any case, 
they are never run implicitly if you define an __init__ in the child 
class: you must run them explicitly.  Since threading.Thread does 
important things in its initializer, you must call it as that web page 
noted.

(Note that because of this, *you* can control when you call the parent 
initializer, whether at the start, end, or middle of your child class 
initializer.)

> 2) Can I assume that constructors run to completion before returning
> and that my later call to start() happens after the constructor
> finished?

Yes, the call to the class (e.g. ServerThreadManager()) doesn't return 
until the object is fully constructed and initialized.

> 3) I'm having weird problems with an assignment in the constructor that
> make me wonder whether I need to know more about thread locks. I do
> this:
...
> Note how I do:
>         self.SocketPacketFragmentsList = []
> and then
> 
> self.SocketPacketFragmentsList.append([self.AcceptListenerSocket,''])
> 
> That works in the sense that I get a length of 1 in the list after the
> append. But I originally did this which did not generate a runtime
> error but which left the tested list length at 0:
>         self.SocketPacketFragmentsList =
> [[self.AcceptListenerSocket,'']]
> 
> The result when tested is len == 0. 

No, it's not.

> Why didn't that work? 

It did work.  Try it again. :-)  If it still looks like it's not 
working, either you're not really doing that, or you are doing the test 
incorrectly.  How and where are you finding the length?

> Also, downstream from the append when I test the
> self.SocketPacketFragmentsList's length in the started thread it is len
> == 0 again. Yet self.SocketList keeps being len == 1 as I expected.

Something removing the contents from the list?  Or rebinding the name? 
Trying printing id(self.SocketPacketFragmentsList) immediately after 
creating the list, then again later where you think the length is now 
zero.  If they show the same value, something is removing the contents 
of the list between the two prints.

-Peter




More information about the Python-list mailing list