Photo by Chris Ried

Use Threading rather than Thread

In an earlier post I used Threads when I should be using threading. The documentation says it builds upon the thread module (renamed _thread):

This module provides low-level primitives for working with multiple threads (also called light-weight processes or tasks) — multiple threads of control sharing their global data space. For synchronization, simple locks (also called mutexes or binary semaphores) are provided. The threading module provides an easier to use and higher-level threading API built on top of this module.

That makes sense, so I should be using the threading module. So why is there a leading underscore on thread? The Style Guide (PEP 8) says it indicates a weak internal use and is not imported when using an asterisk.

There are two ways to use this module. Define a subclass and override the run method or to use the Thread class’s default run method. I’ll use the second method here.

The Python 2.x code I was using looked like this:

import thread
thread.start_new_thread(scroll, (text,))

The new code:

import threading

def scroll(text):
    print(text)

text = 'Example text'
thread = threading.Thread(target=scroll, args=(text,))
thread.start()

It is more readable, arguments are explicit and there’s no ambiguity.

Fluent Python (Ramalho, 2015) suggests using concurrent.futures package with Python 3.x. ThreadPoolExecutor and ProcessPoolExecutor implement interfaces to submit threads or processes respectively for execution.