Switching from JavaScript to Python feels like moving to a city with the same street signs but different traffic laws. The syntax looks friendly and familiar. You see async and await sitting right there in the grammar, so you assume the mental model ports over cleanly. It does not. One habitual pattern from JavaScript silently tanks your Python performance without crashing, without logging an error, and without showing up on a quick code review.

How JavaScript Teaches You to Start and Forget

In JavaScript, an async function call is eager. The moment you invoke it, the engine creates a Promise and the work begins immediately. The event loop is already off to the races. That is why JavaScript developers naturally write code like this:

const userPromise = fetchUser(id);
const ordersPromise = fetchOrders(id);
const user = await userPromise;
const orders = await ordersPromise;

Both network requests are in flight before either await is reached. The first await suspends the current function until fetchUser resolves, but fetchOrders has been humming along in the background since the previous line. By the time you need the orders variable, the second request might already be done. This pattern feels so natural in JavaScript that many developers do not even think of it as a concurrency trick. It is just how async works.

The Python Surprise: A Cold Coroutine

Python uses a different contract. When you call an async def function in Python, you do not start any work. You receive a coroutine object. Think of it as a recipe written on paper. The ingredients are listed, the steps are clear, but nothing is in the oven. Until something explicitly drives that coroutine through the event loop, it remains inert.

Here is the trap. A JavaScript engineer who needs a user and their orders might write this in Python:

user_coro = fetch_user(id)
orders_coro = fetch_orders(id)
user = await user_coro
orders = await orders_coro

It looks concurrent. It smells concurrent. It is entirely sequential.

The first line assigns a dormant coroutine to user_coro. The second line assigns another dormant coroutine to orders_coro. When execution hits await user_coro, Python finally starts the first task and runs it to completion. Only after fetch_user finishes does the interpreter reach await orders_coro and start the second task. Your total execution time is the sum of both I/O operations, not the longest one. You did not run them in parallel. You ran them one after another with extra steps.

Why This Bug Is Invisible

This is the kind of performance regression that survives for months. The code is valid Python. It passes type checkers. It returns the correct results. It just runs at half speed, or worse. Because there is no stack trace and no warning, engineering teams often look everywhere else first. They add Redis caches, upgrade database tiers, or switch hosting regions. The real culprit is a subtle mismatch in expectations about what await actually does.

Three Ways to Make Python Actually Run Things Concurrently

To fix this, you must tell Python’s event loop to schedule the work immediately. You need something more active than a raw coroutine. You need a Task.

1. asyncio.create_task

The most direct translation of the JavaScript pattern is to wrap your coroutine in a Task. A Task is scheduled on the event loop as soon as you create it. It is the closest Python equivalent to a JavaScript Promise in motion.

user_task = asyncio.create_task(fetch_user(id))
orders_task = asyncio.create_task(fetch_orders(id))

user = await user_task
orders = await_orders_task

Now both fetch_user and fetch_orders are in flight before the first await. When you reach await user_task, you pause only until that specific Task completes, but the other Task keeps running. If fetch_orders finishes first, its result simply waits inside orders_task until you ask for it.

Be careful, though. If you create a Task and never await it, Python will emit an error about a destroyed pending task. You must still collect your results.

2. asyncio.gather

If you have several coroutines that all need to finish before you move on, asyncio.gather handles the boilerplate for you. It schedules each coroutine as a Task internally and awaits them together.

user, orders = await asyncio.gather(fetch_user(id), fetch_orders(id))

This is concise and readable. It shines when the operations are independent and you want a single line that expresses "run all of these, then give me every result." It also preserves the order of arguments in the returned list or tuple, even if the underlying tasks complete in a different order.

3. asyncio.TaskGroup

Python 3.11では、標準ライブラリに構造化された並行性（structured concurrency）をもたらすTaskGroupが導入されました。タスクを手動で作成する代わりに、コンテキストマネージャを使用することで、生成されたすべてのタスクが適切に終了することを保証できます。もし1つのタスクが例外を投げると、他のタスクは自動的にキャンセルされます。

async with asyncio.TaskGroup() as tg:
    user_task = tg.create_task(fetch_user(id))
    orders_task = tg.create_task(fetch_orders(id))

user = user_task.result()
orders = orders_task.result()

このパターンは複雑なワークフローに非常に適しています。タスクが孤立（orphaning）するリスクを排除し、関連する操作のライフサイクルを1つの論理的な傘の下にまとめます。コードベースがPython 3.11以降で動作している場合、これはファンアウト（fan-out）並行性を実現するための最もクリーンなアーキテクチャとなることが多いです。

メンタルモデル：await は「今すぐこれを実行せよ」を意味する

本質的な教訓は、言語的な違いにあります。JavaScriptでは、awaitを「その間に（meanwhile）」と読み替えることができます。作業を開始し、他のことを行い、値が必要になったときにだけ一時停止する、というイメージです。一方、Pythonにおけるawaitは、「このコルーチンを次の中断ポイントまたは完了まで進める」ことを意味します。もしコルーチンがまだスケジュールされていない場合、awaitがそれをスケジュールする役割を果たします。そのため、2つの生のコルーチンを開始して、後でそれらをawaitするということはできません。その間、イベントループに実行すべきタスクを何も与えていないことになるからです。

Pythonのコルーチンは、ジェネレータ関数のようなものだと考えてください。ジェネレータを呼び出しただけでは、反復（iterate）は行われません。ループで回すか、next()を呼び出すか、あるいはコンシューマ（consumer）に渡す必要があります。非同期処理も同様です。asyncio.create_taskは、「これを今すぐイベントループに載せろ」と命じるコンシューマの役割を果たします。その後のawaitは、単に完了の合図を待つだけです。

役立つ具体的な習慣が1つあります。awaitを使わずに非同期関数の呼び出しを変数に代入するときは、それがスケジュールされているかどうかを自問してください。もし右辺がcreate_task、gather、またはTaskGroupでラップされていないのであれば、それは実行されていません。それは単にカウンターの上に置かれた「レシピ」に過ぎないのです。

まとめ

Pythonの非同期ランタイムは強力ですが、明示的な意図を必要とします。関数を呼び出したという理由だけで、言語がバックグラウンド作業を開始することはありません。もしJavaScriptから移行してきたのであれば、コルーチンを変数に格納して後でawaitしている箇所をすべて監査してください。最初にそれをTaskに昇格させていない限り、あなたは「非同期の服を着た逐次的なコード」を書いていることになります。まずTaskとして作業を開始し、それから結果を待つ。そうすることで、Pythonの非同期処理を「静かなボトルネック」から「真の並行性ツール」へと変えることができるのです。