Python in Excel vs RTD for live trading data

Microsoft's Python in Excel is genuinely useful — but its execution model is the wrong shape for a continuously-streaming local feed like Interactive Brokers TWS. Here's why, from Microsoft's own documentation.

When Python in Excel shipped, the natural question for anyone pulling broker data into a sheet was: can I just use this to stream my live positions? It's a fair hope, and the answer is no — not because Python is weak, but because of where and when Python in Excel runs. Those two facts, both documented by Microsoft, rule out continuous local streaming.

Where it runs: the Microsoft Cloud

Python in Excel does not execute on your PC. Per Microsoft, "Python in Excel calculations run in the Microsoft Cloud with a standard version of the Python language." The flow is: "You type Python directly into a cell, the Python calculations run in the Microsoft cloud, and your results are returned to the worksheet." Your code runs on Microsoft's servers, not next to your copy of TWS.

And that cloud container is deliberately sealed. Microsoft's security documentation is explicit: "The Python code doesn't have network access," and "The Python code doesn't have access to your computer, devices, or account." Data reaches the container only through the built-in xl() function referencing cells already in your workbook, and results come back only as the output of the =PY() function. Nothing else goes in or out.

That single design choice ends the streaming idea. To stream IBKR data you have to open a socket to TWS or IB Gateway — by default on 127.0.0.1:7496, on your own machine. Python in Excel's container has no network access and can't see your computer, so it cannot reach that socket. It can only ever compute over data that is already sitting in the sheet.

When it runs: on recalculation, not continuously

Even setting the sandbox aside, the timing is wrong. Python in Excel is recalculation-driven: a =PY() cell runs when Excel recalculates it — when its inputs change or you trigger a recalc — and then it's done. There is no long-lived process sitting in the container holding a subscription open and waking the sheet when a new tick arrives. Each run is a fresh, short-lived container that is torn down afterward; as Microsoft puts it, "Once a container is used, it's destroyed. No data persists between sessions or users."

Continuous market and account data is the opposite pattern. It's a firehose that pushes updates at you many times a second, indefinitely, and something has to be listening the whole time. A model that computes once per recalculation and then discards its state has no place to stand.

How RTD is built differently

RTD (Real-Time Data) inverts both facts. An RTD server is a local COM Automation component that Excel loads in-process, and it is push-based: it holds its own connection to the data source, and when a value changes it notifies Excel through a callback so the cell updates on its own. Microsoft's RTD design hands the server a callback object at startup precisely so it can "notify Excel when it should gather updates." The server keeps running for the life of the workbook, listening the whole time.

That is why RTD, not Python in Excel, is the mechanism for a live IBKR trading screen: it runs on your machine (so it can reach your local TWS socket) and it runs continuously (so it can hold a streaming subscription and push ticks into cells without a recalculation to prompt it).

Which to use when

None of this is a knock on Python in Excel — it's excellent for its intended purpose: running analysis, models, and visualizations against data that's in the workbook. It just isn't a pipe for getting streaming data into the workbook. Those are two different jobs, and a live trading dashboard needs the second one.