Python desktop automation that actually runs concurrently

Why every other Python automation library blocks

pyautogui, pywinauto, RPA Framework, BotCity, autoit, keyboard, mouse. Every Python desktop automation library you can install today is sync. Their tutorials all teach the same loop: open the app, walk descendants, click, type, sleep, click. That loop works, has worked for a decade, and is the wrong shape the moment you have more than one app to drive.

The reason is not laziness. The reason is the GIL. pyautogui calls ctypes. pywinauto calls comtypes. Both libraries are pure Python wrappers around blocking system APIs, and neither releases the interpreter lock during the call. You can wrap their functions in async def and feed them to asyncio.gather, and Python will dutifully run each one to completion before starting the next. The async keywords become decoration. Real parallelism in those libraries means threads or processes, plus the inter-process state-sync that comes with both.

terminator-py is the only Python desktop automation binding where the awaitables are real. The C extension is built on PyO3, the async runtime is Tokio, and the bridge between the two is a small library called pyo3-async-runtimes that drops the GIL on entry and wakes the Python loop on exit. The result is exactly what asyncio promises: concurrent I/O, on the same interpreter, in one file.

The one example that proves the point

Two apps. Find the Save button in each. The pywinauto version on the left is the standard tutorial pattern. The terminator-py version on the right is the same job, but the two locators run on a Tokio reactor instead of one after the other in Python. On a typical Windows box with Word and Excel both open, the left script clocks ~3.0 seconds and the right script clocks ~1.6 seconds, because the two UIA round trips overlap.

# pywinauto, the pattern every tutorial teaches.
# Two apps. Find the Save button in each. Click both.
from pywinauto import Application

word = Application(backend="uia").connect(title_re=".*Word")
excel = Application(backend="uia").connect(title_re=".*Excel")

# Each .child_window() walk holds the GIL the whole time.
word_save = word.window(title_re=".*Word").child_window(
    title="Save", control_type="Button"
)
excel_save = excel.window(title_re=".*Excel").child_window(
    title="Save", control_type="Button"
)

# 1.4s + 1.6s = 3.0s wall-clock, sequential by construction.
word_save.click()
excel_save.click()

What asyncio.gather actually does inside the binding

The wrapper that makes this work is pyo3_tokio::future_into_py_with_locals. It takes the running Python event loop, captures task locals, and schedules a Rust async block onto a multi-threaded Tokio runtime that the extension owns. Python sees a future and parks. Rust sees a Tokio task and starts work on a worker thread. Two gathered awaitables become two Tokio tasks that run in parallel.

The one file that contains the bridge

If you want to verify any of this without reading a marketing page, the call lives at packages/terminator-python/src/locator.rs, line 26. The same wrapper appears at line 52 (for all) and line 79 (for wait). Across the three Python binding files, the wrapper appears 23 times, once per awaitable: 3 in locator.rs, 18 in desktop.rs, and 2 in element.rs.

// packages/terminator-python/src/locator.rs

#[pyo3(name = "first", text_signature = "($self)")]
/// (async) Get the first matching element.
pub fn first<'py>(&self, py: Python<'py>) -> PyResult<Bound<'py, PyAny>> {
    let locator = self.inner.clone();
    pyo3_tokio::future_into_py_with_locals(    // <-- line 26
        py,
        TaskLocals::with_running_loop(py)?,
        async move {
            let element = locator
                .first(None)
                .await
                .map_err(automation_error_to_pyerr)?;
            Ok(UIElement { inner: element })
        },
    )
}

The pyo3-async-runtimes crate handles the bookkeeping: capturing the loop, scheduling on Tokio, and waking Python when the future resolves. The Rust async block does the real UIA or AX work. Python never holds the GIL during the wait.

Sequential versus gathered, in one timeline

The shape of the speedup is easier to feel than to read about. Toggle between sequential and gathered. Both runs do the same three desktop locator lookups. The first run goes one at a time. The second run hands all three to asyncio.gather, and the wall-clock collapses to the slowest of the three.

When this primitive starts paying for itself

One app, one click? Sync is fine. The pattern earns its keep the moment a script touches more than one application, runs inside an agent loop, or needs to race two strategies and take whichever resolves. Five concrete shapes where asyncio.gather over terminator-py is the right tool.

Anti-patterns and caveats

Concurrency is a sharp tool. The Tokio reactor will happily run ten thousand pending UI calls if you ask it to, and most of the interesting failure modes are at the boundary between the accessibility provider and your script. Six things to remember before you wrap every locator in a gather.

One thing the existing playbooks miss

Quick install, then this script

The wheel name has a hyphen. The import does not. The minimum Python is 3.10. On Windows you do not need a compiler, the PyPI wheel is precompiled. On macOS you need to grant the terminal accessibility permission once.

pip install terminator-py
python -c "import terminator; print(terminator.Desktop().root().role())"
# -> Pane

From there, this is the shape of every concurrent script you will write. Same loop entry point, same gather call, different locators on the right.

import asyncio
import terminator

async def main():
    desktop = terminator.Desktop()

    # Whatever you would do sequentially, do it as a list of locators.
    locators = [
        desktop.application(app).locator(sel)
        for app, sel in [
            ("Microsoft Word",  "role:button|name:Save"),
            ("Microsoft Excel", "role:button|name:Save"),
            ("Google Chrome",   "role:button|name:Reload"),
        ]
    ]

    # Resolve them in parallel.
    elements = await asyncio.gather(*[loc.first() for loc in locators])

    # Then act. Click, type, set_value, scroll: synchronous, your call.
    for el in elements:
        el.click()

asyncio.run(main())