class Thread doesn't reset self.__started after run() has terminated, so one cannot reuse 
the thread class and run start() again.

Logged In: YES 
user_id=31435

It's true that Thread instances can't be restarted, but you 
haven't made a case for calling that "a bug".  Python's 
threading model is fashioned loosely on Java's, and, like 
Java's, limits thread instances to one invocation by design.

Logged In: YES 
user_id=357491

I agree with Tim here.  I don't see a need for this anyway.  Once 
a thread has terminated it is done, period.  Having to 
reinstantiate a class to run another thread is perfectly 
reasonable.

Logged In: YES 
user_id=647640

Maybe I should state some reasons for adding this functionality:

Imagine, you wish your thread to do some background work
while normal execution goes on (e.g. parsing a website).
It's a small task doing execatly the same job over an over.
If that will happen often, the overhead of creating a new
object might be too hight, especially if your object holds a
lot of data. And sometime the garbage collector will kick in...
If you want to write a really small class build from several
mix-in classes and Thread that only seldom needs to run
start(), you could use all member functions and variables.
Nice and neat.
And last but not least it wouldn't break compatibility.
Programs using threadying.py needn't change a single line.
There are more pro's and con's to this. To my opinion it is
more a matter of coding style and design. I do not know
Java's threads but I agree now with time_one: maybe this
issue is more a feature request than a bug report.

Logged In: YES 
user_id=50945

> Imagine, you wish your thread to do some background work
> while normal execution goes on (e.g. parsing a website).
> It's a small task doing execatly the same job over an over.
> If that will happen often, the overhead of creating a new
> object might be too hight, especially if your object holds a
> lot of data. And sometime the garbage collector will kick
in...

Asking for this feature on the basis of performance sounds
bogus to me.  I'd expect creating and finishing threads to
be more expensive than the usual way to do this, which is to
have the one thread process chunks of work delivered via a
Queue.Queue (as opposed to creating a short-lived thread for
each chunk of work).

If you really think performance is the issue here, do some
benchmarking of the way things work at the moment versus
your proposal, versus long-lived threads using Queues.  If
you have some compelling numbers, then you'll have more
chance of convincing people this needs to be done.  (But my
guess is you'll find long-lived threads are more efficient.)

Logged In: YES 
user_id=357491

What Andrew said.  =)  Although I realize if you did already know 
how to make this work you would have made this a patch.

I am reclassifying this as a feature request instead of a bug since 
the code isn't broken; you just want it to do something that it is 
not designed to do at the moment.

Closing as won't fix.  Python's threads work
as designed.  There are plenty of solutions
available to get the desired behavior.

Close it for real