Thread by @willmcgugan

A while back I was struggling to manage async creep in Textual ("async creep" is the tendency for all methods to become async).

A *single method* in asyncio allowed me to reverse that decision, and prevent asyncio creep. #Python

🧵

First, the reason why I disliked asyncing all the things.

The "await" keyword is boilerplate. Its existence is mostly for the language and doesn't help the developer.

Whether you do "await foo()" or "foo()" you are invoking the function. The majority of the time the await keyword is a burden placed on the developer to remember wether it is a coroutine or not.

Now that isn't entirely accurate. Seeing those `await` keywords is an indication that Python may run some other code while awaiting for a result.

And when I'm working on framework code, that can be beneficial. And certainly a boon over writing threading code where there are no guarantees when another thread may run.

But outside of the framework, a developer building a Textual app just wants to call the function. And I don't want to force them to remember to make all their functions async, and await all of the API.

There's some great tooling that helps with this, but it's still extra to think about and type. It's almost always boilerplate.

Originally I didn't think it was possible to avoid. Textual is built on async and if you wanted to use it you would have to master asynchronous programming.

It turns out it is quite easy to avoid with that one trick that framework developers don't want you to know. 🤡

Every component in Textual has a "message pump" which is an asyncio task reading messages from an asyncio.Queue.

This Queue object has a "put_nowait" method which adds a message to the queue, but importantly is not a coroutine (hence _nowait).

Many of the Textual API functions (regular non async) call put_nowait to add a message to the queue.

This message is then picked up by an asyncio task which results on an action. It's essentially a bridge between the async and sync domains.

So most of the Textual API doesn't need to be async. Developers who aren't familiar with async and await (and there are plenty of those) could still build a Textual app.

The downside of "put_nowait" is that you can't get a response from the messages, as it will be processed in the near future, but the caller can't say when.

For Textual this doesn't seem to matter too much. The application code is independent from updating the screen. If you update something it is enough to know that the "screen" will eventually update (within a few milliseconds).

Textual API methods that do need a return value, generally don't need to do anything asynchronous anyway.

The other technique to avoid async creep is something I've talked about before.

Textual will inspect message handlers to see if they are coroutines or not. If they are, they will be awaited, otherwise its a plain old function call.

So as far as Textual is concerned both these are valid:

def on_mount(self):
...
async def on_mount(self):
...

Ultimately in Textual I would like async to be available if the developer needs it, but optional if the developer doesn't need async or doesn't understand it.

This Tweet ramble brought to you by a very smooth Papua New Guinea Arabica roast.