Dabbling with Python again

My relationship with Python is a coming-and-going one. I was recently chatting with Oliver and he asked me what I didn’t like of Python and I said the answer was subjective, but didn’t have an otherwise straight, concise, informed answer. It’s more about feeling, actually. I want to have a better answer.

I currently prefer Ruby to Python, but I want to like Python. I’m not interested on finding out which one is better or picking a winner, I want to be fluent on both languages and use whichever does the best job for the task. I wouldn’t rewrite my Ruby xdotool wrapper in Python, for example. And I wouldn’t rewrite my code generator written in PHP because PHP is something Python and Ruby are not: a templating language. Best tool for the job.

While I can do (and have done) stuff with Python, I don’t consider myself a good Python programmer. There’s lots of gaps in my knowledge. I don’t feel comfortable with it. There goes that feel thing again, dargh. Whatever, I just want to learn Python properly.

I rewrote my latest Ruby script to Python, it automates getting the day’s Zoom invitation for sending it to my church’s WhatsApp group. Surely there’s better, pythonic ways of doing things, but it works and it gave me a better understanding on how to do things in Python based on how I usually write them in Ruby.

And I learnt about assignment expressions. I didn’t know Python couldn’t do that and I’m glad they added them to the language already. The reason behind them was exactly what I stumbled with: having a condition where a regular expression matches and needing the match object assigned to a variable. I was like, “why can’t I assign in a condition?”

Trying xdotool and pyautogui

I tried xdotool and it’s pretty cool. I was automating setting up my Slack status. It finds the Slack window, focuses it, clicks here and there and — tah-dah! — my status is updated. It totally depends on things being in fixed places, but it works.

Then I tried pyautogui planning to port this script and see how it compares with xdotool, but I was surprised right from the start to discover pyautogui doesn’t have any feature to find or operate on windows. So I’ve decided to stick with xdotool and dive deeper. I might try pyautogui some other time.

One thing I liked about pyautogui is it’s “failsafe” — if you slam the mouse and move the cursor to any screen corner, pyautogui will stop running. This is a great feature. One automation of mine with xdotool didn’t quite work (the popup appeared too late) and suddenly xdotool was blindly doing stuff on the wrong places and I couldn’t stop it. No damage was done, but it was scary.

I totally needed something like pyautogui’s, but this required a higher-level language. I went with Ruby. My failsafe is the top or bottom edge of the screen. Before it executes any xdotool command it checks the mouse location and throws an exception. Works pretty well and I recurred to it when I made a mistake and the automation misbehaved.

Lesson learnt: automating the GUI is powerful, but also dangerous. Unlike a shell script, the GUI is an unpredictable environment and things can quickly derail. I like the way pyautogui’s documentation describes this:

Like the enchanted brooms from the Sorcerer’s Apprentice programmed to keep filling (and then overfilling) the bath with water, a bug in your program could make it go out of control. It’s hard to use the mouse to close a program if the mouse cursor is moving around on its own.

It’s a powerful, but double-edged sword. And lots of fun too! Automating the GUI is another dimension and a very useful skill to have.