Adaptive Waiting as a Complement to PyAutoGUI

[LuizSeabraDeMarco]

Hi PyAutoGUI maintainers and community 👋

I wanted to share an open-source experiment that complements PyAutoGUI, especially around one common pain point: fixed waiting times (e.g. time.sleep).

I built a small Python library called Nano-Wait that introduces adaptive waiting — instead of sleeping for a fixed duration, it dynamically adjusts wait time based on system context and (optionally) visual feedback from the screen (OCR).

The goal is not to replace PyAutoGUI, but to be used alongside it in automation flows where timing is unstable across different machines, networks, or UI states.

Example use cases:

• Reducing flaky automation caused by hardcoded sleeps
• Waiting for UI changes rather than elapsed time
• Screen-based decisions before triggering PyAutoGUI actions

https://pypi.org/project/nano-wait/

If this kind of approach aligns with PyAutoGUI’s ecosystem, I’d love to hear feedback or suggestions from the community.

[mark-wilsons-verizon-discounts]

Couldn't a pyautogui user just poll and busywait for screen state normally? Are you looking to integrate this into pyautogui itself?

[LuizSeabraDeMarco]

Hey! Great question 😄

• Polling / busy-wait is simple but can waste CPU and doesn’t adapt to system load.
• Nano-wait adjusts waits based on CPU, RAM, Wi-Fi, and works well with loops, async tasks, and PyAutoGUI.

One downside: slightly more setup with dependencies.

Many advantages: CPU-friendly, reliable under load, async/parallel ready, logs/telemetry, and stable on all platforms.

I’d love to hear your thoughts — how do you feel about using something like nano-wait in your projects?

[mark-wilsons-verizon-discounts]

in a real project I'd probably just poll myself
adjusting based on weak ram/cpu/network heuristics seems brittle and overengineered

[LuizSeabraDeMarco]

That’s totally fair — I agree that in many real-world cases, just polling directly is clean and explicit.

My goal isn’t to replace that pattern or rely on fragile heuristics, but to offer a small abstraction that keeps things simple (usually 1–2 lines), avoids tight busy loops, and reduces flakiness compared to fixed sleeps.

If you’re comfortable tuning polling yourself, that’s probably the most predictable approach. I’m mainly experimenting with making that pattern reusable and slightly less boilerplate-heavy.

I really appreciate the pushback — it helps refine the idea. How do you usually structure your polling loops in automation projects?