I think the previous wording was fine ("in each thread").

Mhm, the previous wording was certainly less clunky. This paragraph describes how asyncio automatically associates tasks with the event loop, and I'm worried the reader may be left wondering how that works when there are multiple event loop objects in the same process memory space.

I've reworked it to this, which I think flows more smoothly. Let me know!

"
asyncio automatically associates tasks with the event loop for you. In many applications there's only a single thread with the one event loop, but you can have multiple threads, each with their own event loop. Each event loop is stored in thread-local storage, making it easy for asyncio to associate tasks with the relevant loop for each thread.
"

I think this is really overcomplicating it for the reader. asyncio is generally supposed to be "concurrency without multithreading", so having several sentences about threads is hurting that idea a little bit. We should keep it simple; a single sentence or little note about the event loop being thread-local is fine.

Ok. Does this mean you're on board with the original change: "(per thread; in thread-local storage)", then? I agree we shouldn't go too deep into threads, and trust me I'm trying not to, but I think bringing up threads and failing to mention how asyncio still accomplishes task to event loop pairing may confuse folks.

We could do something like:

asyncio automatically associates tasks with the event loop for you. Typically there's only one event loop, so that's quite straightforward. It's uncommon, but some applications use multithreading and asyncio together, with one event loop per thread in thread-local storage.

I'm happy with the latter change (with a few changes, but I'll suggest those if you add it), or a variation of the original change: "per thread, using thread-local storage".

Kk. Went with the latter change. Just pushed 👍

Hm, "data structure" is probably the vaguest term in all of programming. We could just say that the event loop "works through its processing logic".

Ehhh, come on, I don't think it's the most vague nor more vague than "processing logic". I think it gives more insight into why there's overhead introduced -- managing internal state.

Out of curiosity, do you have a vaguer term in mind as a counterexample 😄

But seriously, I like the phrase "managing internal state" better than "manage its data structures". Can we say that instead?

Hah! Hmmm. Perhaps things, routines, series of steps, computation, process, even work-chunk ;)

For reference, I do genuinely feel data structures is fairly clear (even though it's clear we disagree!). To me, it refers to things like queues, trees, hash tables, sets, etc. as opposed to procedural logic. And in this case, particularly ones that need to maintain some invariant as they perform operations.

But, yes, happy to go with that change 👍

"stored in thread-local" is unnecesary implemenetation detail for the reader, just per thread seems sufficient.

See discussion here: #138073 (comment)

I prefer the original for two reasons.

The titles come from the references made in the broader await section intro.

And they fit more naturally in the broader table of contents: