No threading.start_new_thread(), useful addition?

Carl Banks pavlovevidence at gmail.com
Fri Oct 9 22:35:05 CEST 2009


On Oct 8, 5:03 am, Ulrich Eckhardt <eckha... at satorlaser.com> wrote:
> sturlamolden wrote:
> > On 8 Okt, 09:17, Ulrich Eckhardt <eckha... at satorlaser.com> wrote:
>
> >> I'm looking at the 'threading' module and see that other than the
> >> 'thread' module it doesn't have a simple function to start a new thread.
> >> Instead, you first have to instantiate a threading object and then start
> >> the new thread on it:
>
> >> t = threading.Thread(target=my_function)
> >> t.start()
>
> > One usually want to subclass threading.Thread instead of specifying a
> > target function.
>
> No. You also don't derive from a file class in order to read a file. The
> point is that the Thread instance is not a thread but it is an object that
> can be used to access a thread, similar to a File instance which file which
> is not the file but just an object to access one.
>
> I personally find it much cleaner this way. Also, why should any code care
> in which thread it is executed? Why should I have to derive a class from
> some other only because I want to run one of its functions in a separate
> thread?

I have to agree.  I've been trying to understand some other entity's
Java code lately, and it's mondo-confusing because there is a subclass
of Thread that has methods that are called from other threads.  To
make matters worse the variable this method is assigned to is called,
simply, "thread".

As far as I can discern doing that way (as opposed to using a Runnable
object) didn't have any effect except to make the logic harder to
understand.

So (getting back to Python) count me among those who say one usally
want to specify a target function instead of subclassing
threading.Thread.


Carl Banks



More information about the Python-list mailing list