Boardflare Python for Excel vs. Microsoft Python in Excel

Boardflare Python for Excel and Microsoft Python in Excel both connect Python to an Excel workbook, but they use substantially different programming models.

Microsoft makes Python part of the worksheet calculation surface: Python code is authored in PY cells, those cells participate in a workbook-wide Python calculation sequence, and results return as Python objects or Excel values.

Boardflare makes a reactive marimo notebook the primary Python program: workbook references are declared as notebook inputs, marimo tracks Python dependencies, and selected values or functions are explicitly published back to Excel.

Those differences affect more than editing preference. They change calculation order, code organization, recalculation, source portability, workbook integration, package/network capabilities, security boundaries, and the kinds of Excel applications each model naturally supports.

:::info Verification date Microsoft behavior on this page was checked against Microsoft's public documentation on August 14, 2026. Boardflare behavior is based on the implementation contracts shipped with the add-in. Both products can change; use the linked source documentation when a deployment decision depends on a specific current limit or availability rule. :::

The short version

Question	Microsoft Python in Excel	Boardflare Python for Excel
Where does the Python program live?	In PY worksheet cells, with a workbook-level initialization surface	In one marimo .py notebook saved with the workbook
What determines execution order?	Row-major Python-cell order, including worksheet order	Python variable dependencies in marimo's reactive graph
What happens when an input changes?	Python formulas recalculate sequentially	Affected notebook cells and their descendants rerun
Can Python remain a Python object in a worksheet cell?	Yes	No generic Python-object worksheet cell; publish Excel-compatible values instead
Can one Python callable become a reusable worksheet function?	PY itself cannot be nested with other Excel functions	Yes, through BF.FUNCTION("name", ...)
Can code make arbitrary web requests?	No; Python has no network access	Browser-compatible requests are possible, subject to browser/CORS rules
Can Python read Power Query connections directly?	Yes, through xl()	No equivalent public notebook input contract
Can the complete program be downloaded as .py?	Microsoft documents editing all PY cells, but not a native whole-workbook .py export	Yes; the notebook is downloadable/uploadable Marimo .py source
Where does Python execute?	Hypervisor-isolated Microsoft Cloud container	Browser/WebAssembly Pyodide runtime inside the add-in
Main design center	Python analysis embedded in the Excel calculation grid	A coherent reactive Python application connected to Excel

Neither model is universally better. A bounded pandas calculation that belongs directly in the grid can be a very natural Microsoft Python in Excel workload. A larger analysis with reusable Python functions, interactive controls, substantial source, or a source-control workflow can fit a notebook model more naturally.

1. Programming model: worksheet program vs. notebook program

Microsoft documents the PY function as executing static Python source on its cloud runtime. The normal user experience hides the formula syntax behind a Python editor, but the underlying workbook still contains Python formulas. Microsoft's Python code editor shows all Python cells in a workbook, organized by worksheet and cell number.

Conceptually:

Microsoft Python in Excel

Workbook
├── Setup!B2       import / setup Python
├── Model!C8       transformation Python
├── Model!F20      analysis Python
├── Report!B4      chart Python
└── Report!G12     summary Python

The program is distributed across workbook coordinates.

Boardflare stores one notebook source artifact with the workbook:

Boardflare Python for Excel

Workbook
└── notebook.py
    ├── imports
    ├── workbook inputs
    ├── transformations
    ├── models
    ├── checks
    ├── charts / controls
    └── published outputs / functions

The distinction matters most as the amount of Python grows. In Microsoft's model, worksheet position is part of program structure. In Boardflare, worksheet cells provide inputs and consume selected results, while the Python program itself remains a coherent source file.

When this difference matters

Microsoft can be simpler when:

• a Python calculation belongs naturally beside the worksheet values it analyzes;
• users expect the worksheet grid to remain the main authoring surface;
• Python object cards are useful intermediate worksheet artifacts;
• the organization strongly prefers a native Microsoft-managed calculation feature.

Boardflare can be simpler when:

• the Python becomes a substantial program rather than a few calculations;
• code review is easier when imports, functions, transformations, tests/checks, controls, and output publication are visible together;
• moving worksheet content should not implicitly reorganize Python execution;
• the Python source needs to leave the workbook as a normal .py artifact.

2. Calculation order is fundamentally different

This is one of the most important architectural differences.

Microsoft's Get started with Python in Excel documentation states that Python cells calculate in row-major order. Excel evaluates Python cells across a row from left to right, then proceeds to following rows. The same rule applies across worksheets according to worksheet order. Variables must therefore be defined in an earlier Python cell before a later Python cell references them.

Microsoft also documents that when a dependent value changes, all Python formulas are recalculated sequentially. Manual and Partial calculation modes can suspend that work; current availability depends on Microsoft 365 licensing. See Python in Excel availability.

Boardflare uses marimo's reactive dataflow model. Cell order in the notebook is a presentation/editor order; execution follows variable definitions and references.

If only the forecast assumptions change, the cells depending on those assumptions rerun. An unrelated notebook branch does not need to rerun merely because it appears later on screen.

Practical consequences

Change	Microsoft Python in Excel	Boardflare
Move a Python cell earlier/later	Can change whether variables have been defined before use	Does not change dependency semantics merely because visual position changes
Reorder worksheets	Can change cross-sheet Python execution order	Does not define notebook dependency order
Change one upstream input	Python formulas recalculate sequentially	Affected reactive descendants rerun
Define the same global name in competing cells	Later sequential state can depend on earlier Python cells	marimo treats conflicting definitions as a dependency problem rather than an implicit overwrite pattern

This does not by itself prove that one product is faster. Actual performance depends on the workload, runtime, package behavior, data transfer, and calculation settings. It does mean the two products have different recalculation semantics and different failure modes as a workbook evolves.

3. Source size and how larger programs are represented

Boardflare has an explicit implementation limit of 200,000 UTF-8 bytes for the saved Marimo notebook source. The complete workbook Custom XML part that contains the source and metadata is limited to 1,000,000 bytes.

Microsoft uses a different storage model. PY stores static Python source in each Python formula, and Microsoft's code editor provides a larger editing surface for code blocks while showing all Python cells in the workbook.

Excel's general specifications and limits document an 8,192-character formula-content limit, but Microsoft does not currently document that number as a Python-specific maximum source limit. Because the Python editor abstracts the generated PY formula representation, this page does not claim that a PY cell is verified to have an 8,192-character Python limit.

The reliable comparison is therefore:

Source question	Microsoft	Boardflare
One documented whole-program source limit	No whole-workbook Python-source limit documented	200,000 UTF-8 bytes for the notebook
Storage unit	Individual PY cells plus workbook initialization settings	One Marimo .py source artifact
Larger program strategy	Distribute code among Python cells; edit them together in Code Editor	Keep the program in the notebook, subject to the source limit
Generic Excel formula limit	Excel documents 8,192 characters, but that is not documented as a PY-specific source cap	Not the notebook source-storage mechanism

For a ten-line analysis, this distinction may be irrelevant. For hundreds or thousands of lines of Python, the organization of the source becomes part of maintainability.

4. Source export, backup, and version control

Boardflare's notebook is a normal Marimo .py source representation. In Edit mode, users can download the latest source already submitted to Boardflare and can upload a replacement .py file. Uploaded source is staged first and does not replace the workbook's saved source until Marimo Save succeeds.

Microsoft's Code Editor significantly improves large-code editing by showing every Python cell in one task pane with IntelliSense and syntax colorization. Microsoft also documents that add-ins can read and write the underlying PY formulas and that FORMULATEXT can expose them.

However, Microsoft's current public documentation does not describe a native command that exports all workbook Python cells as one .py program. External tooling could extract formula source, but that is a different source-control workflow from a workbook carrying one directly downloadable Python file.

When this difference matters

Boardflare's model is useful when teams want to:

• review the Python in ordinary text diffs;
• archive the code separately from the workbook;
• use pull requests or other repository workflows;
• develop a notebook source artifact outside the workbook and load it back later.

Microsoft's model can be preferable when the workbook itself is intentionally the unit of code ownership and users do not need a separate Python artifact.

5. Excel-to-Python input model

Microsoft Python in Excel uses xl() as its workbook bridge. Microsoft documents support for:

• ranges;
• defined names;
• tables;
• images;
• Power Query connections.

The workbook's initialization settings configure default conversion behavior. Microsoft's current defaults use a scalar converter for scalar input and a DataFrame converter for array input. Two-dimensional ranges therefore default to pandas DataFrames. See Python in Excel initialization settings and the PY function reference.

Boardflare requires the notebook to declare the workbook data it consumes:

import boardflare as bf

inputs = bf.inputs(
    tax_rate="Assumptions!B4",
    sales=bf.ref("Sales!A1:D500", headers=True),
)

rate = inputs["tax_rate"]
sales = inputs["sales"]

The current Boardflare materialization contract is:

Excel reference	Boardflare Python value
One cell	Scalar workbook value
Multiple cells	pandas DataFrame
Multiple cells with headers=True	DataFrame using the first row as columns

Boardflare's explicit input registry is designed to make notebook dependencies inspectable and reactive. It is intentionally narrower than a general workbook object model.

Capability differences

Input capability	Microsoft xl()	Boardflare notebook API
Cell/range	Yes	Yes
Defined name	Yes	Yes
Table / structured reference	Yes	Yes for table references such as Table1, Table1[#Data], [#Headers], [#Totals], and simple column selectors
Headers → DataFrame columns	Yes	Yes, headers=True
Image reference	Yes	No equivalent public input contract
Power Query connection	Yes	No equivalent public input contract
Arbitrary workbook formulas/charts/VBA inspection	No	No

Both products can reference worksheet ranges, names, and tables. Microsoft has a clear advantage when direct Python access to a Power Query connection or image object is central to the workflow. Boardflare's narrower contract has a different advantage: the notebook declares a small, explicit set of reactive workbook dependencies instead of receiving broad workbook access.

6. Input scale limits are not apples-to-apples

Microsoft documents that a Python in Excel calculation can process up to 100 MB of data at a time. Exceeding that upload boundary returns a #CALC! error. See How to correct a #CALC! error.

Boardflare's workbook bridge currently applies protocol-level bounds instead:

• maximum 128 declared notebook inputs;
• maximum 100,000 cells in one referenced range;
• maximum 250,000 cells across active input ranges;
• maximum 512 KiB encoded input snapshot;
• maximum 1 MiB encoded capability message.

These limits measure different things. Microsoft's 100 MB boundary is data sent to its cloud Python service per calculation. Boardflare's limits bound the live browser capability protocol between the workbook host and notebook runtime. Do not compare 100 MB and 250,000 cells as if they were equivalent capacity measurements.

Scenario implication

If your workload requires directly loading a very large worksheet payload into one Python calculation, test the real workbook in both products rather than extrapolating from headline limits. Boardflare's current live-input protocol is intentionally bounded and may require narrowing the worksheet input before analysis.

7. Python-to-Excel output and type conversion

The output models differ even more than the input models.

Microsoft: Python object or Excel value

Microsoft lets each Python calculation return either:

• a Python object, displayed as a card in the worksheet; or
• Excel values, translated to their closest Excel equivalents and spilled into the grid when needed.

DataFrames can remain as Python objects for reuse by later Python cells or can be converted to Excel values for formulas, charts, and formatting. See Python in Excel DataFrames.

This means a DataFrame, image, and other supported Python objects can have a worksheet-cell identity without first being flattened into ordinary cell values.

Boardflare: explicit publication to an Excel matrix

Boardflare keeps arbitrary Python objects inside the notebook. Values only cross back into the worksheet when explicitly published:

bf.publish(outputs={"summary": summary})

and consumed:

=BF.OUTPUT("summary")

Published outputs and BF.FUNCTION results use one strict conversion contract. Current behavior includes:

Python value	Boardflare worksheet result
str, bool, finite number	Corresponding Excel scalar
None	Blank cell
pandas missing value / NaT	Blank cell
floating-point NaN	Blank cell
date, datetime, time	Excel serial value using the workbook date system
timedelta	Excel day fraction
pandas Series	One-column result
pandas DataFrame	Rectangular values; DataFrame index/column labels are not automatically added
NumPy 1-D array	One-row result
NumPy 2-D array	Rectangular result
Positive/negative infinity	Error: cannot be represented
Integer outside JavaScript/Excel exact safe range	Error unless converted to text
Ragged or 3-D container	Error
Unsupported arbitrary Python object	Error; keep it in the notebook or convert it explicitly

A single published result is limited to 100,000 worksheet cells.

Direct conversion comparison

Microsoft exposes workbook-level conversion hooks through its initialization settings, so its input behavior is not a single immutable mapping. The defaults are excel.convert_to_scalar for scalar references and excel.convert_to_dataframe for arrays. Microsoft publicly documents the broad conversion model, but its Support pages do not enumerate every edge case such as None, NaN, infinities, or very large integers. Those cases are marked accordingly rather than guessed here.

Case	Microsoft Python in Excel	Boardflare
One numeric/text/Boolean cell → Python	Default scalar conversion	Scalar value
Multi-cell range → Python	pandas DataFrame by default	pandas DataFrame
Header handling	xl(..., headers=True)	bf.ref(..., headers=True)
Input conversion customization	Workbook initialization settings can replace scalar/array converters	Public notebook input contract is fixed
DataFrame → worksheet	Python object card or Excel values	Explicit rectangular worksheet values through BF.OUTPUT / BF.FUNCTION
Arbitrary Python object → worksheet	Many supported values can remain Python object cards	Not a generic worksheet object type; explicitly convert/publish supported values
None → Excel value	Edge-case mapping not enumerated in current Microsoft Support documentation	Blank cell
pandas missing / NaT	Edge-case mapping not enumerated in current Microsoft Support documentation	Blank cell
floating-point NaN	Edge-case mapping not enumerated in current Microsoft Support documentation	Blank cell
positive/negative infinity	Edge-case mapping not enumerated in current Microsoft Support documentation	Deterministic conversion error
very large integer	Edge-case mapping not enumerated in current Microsoft Support documentation	Error outside ±9,007,199,254,740,991 unless converted to text
date / datetime / time	Returned as the closest Excel equivalent when output as Excel values; exact edge-case mapping should be verified for the target environment	Converted to Excel serial using the workbook 1900/1904 date system
timedelta	Exact edge-case mapping not enumerated in current Microsoft Support documentation	Excel day fraction
pandas Series	Can remain a Python object or be converted to Excel values	One-column worksheet result
NumPy 1-D / 2-D array	Can be returned through Microsoft's Python/Excel conversion model	One-row / rectangular worksheet result

This asymmetry is itself useful information. Boardflare's worksheet publication layer intentionally specifies a narrow deterministic value contract. Microsoft intentionally provides a richer Python-object model and configurable conversion layer; for edge cases that matter to a regulated or numerically sensitive workbook, verify the current Excel build rather than assuming Boardflare's mapping applies to Microsoft.

Why this matters

Microsoft's object-card model is advantageous when an intermediate DataFrame or plot should itself live in a worksheet cell and be consumed by later Python cells.

Boardflare's explicit publication model is advantageous when the workbook boundary should remain narrow and deterministic: notebook internals can use arbitrary Python objects, while only selected Excel-compatible results become worksheet data.

8. Reusable worksheet functions

Microsoft documents an important restriction on PY: the PY function cannot be used with any other Excel functions. Its code and return type must be static.

Boardflare supports a different pattern: a callable defined once in the notebook can be published into a registry and called from normal worksheet formulas.

def discount(price, rate):
    return price * (1 - rate)

bf.publish(functions={"discount": discount})

=BF.FUNCTION("discount", A2, B2)

This distinction matters for workbooks where ordinary Excel formulas need to call one centralized Python implementation repeatedly.

Example scenarios

One analytical calculation in a cell: Microsoft PY is a direct, native fit.

One Python algorithm reused in hundreds of worksheet rows: Boardflare's BF.FUNCTION model avoids copying the Python implementation into hundreds of Python cells. The worksheet formulas refer to one published callable while the implementation remains in the notebook.

BF.FUNCTION depends on the notebook session being available; it is not a standalone server-side UDF service.

9. Reactive UI and application-style workflows

Microsoft Python in Excel centers the worksheet. Python results can drive Excel charts and other worksheet analysis, and Python can also return images and object cards.

Boardflare's primary surface is a full Marimo notebook. The notebook can include:

• Markdown explanations;
• reactive UI controls;
• tables and charts;
• intermediate diagnostic output;
• validation messages;
• application-style layouts;
• reusable Python functions.

The same saved notebook can optionally reopen using Open as: App, which simplifies the notebook presentation for repeatable operation. App mode changes the presentation, not the workbook trust or permission boundary.

If the desired artifact is an interactive analytical tool beside a workbook, the notebook surface is a material architectural difference—not just a larger code editor.

10. Packages and runtime ownership

Microsoft runs Python in a Microsoft-managed cloud environment based on an Anaconda distribution. Microsoft provides core libraries such as pandas, NumPy, Matplotlib, seaborn, and statsmodels and a broader curated package set. Users cannot install arbitrary local packages into that runtime. See Open-source libraries and Python in Excel.

Boardflare runs Python through Pyodide/WebAssembly in the add-in's browser environment. Pure-Python packages and packages available for Pyodide are the natural fit; compatible wheels can also be installed with browser/Pyodide tooling. Packages that require unsupported native system dependencies, desktop services, or operating-system access are not appropriate for this runtime.

Runtime question	Microsoft	Boardflare
Runtime owner	Microsoft	Boardflare ships a browser/Pyodide runtime based on stock Marimo
Local Python install required	No	No
Core scientific packages	Managed Anaconda environment	Pyodide environment
Arbitrary local/native package install	No	No; must be browser/Pyodide compatible
Environment consistency	Microsoft versions workbook Python environments and prompts upgrades	Boardflare controls the shipped Marimo/Pyodide runtime; notebook source persists with the workbook

For either product, verify the exact packages required by a production workbook before choosing the runtime.

11. External data and network access

Microsoft deliberately gives Python in Excel a restrictive network boundary. Microsoft's data security documentation states that Python code:

• has no network access;
• has no access to the user's computer or devices;
• has no user token;
• can receive referenced workbook values and external data already brought into Excel through supported mechanisms such as Power Query.

Common functions such as pandas.read_csv() and pandas.read_excel() cannot be used to fetch arbitrary external sources in the cloud runtime. Microsoft directs users to Power Query for external data ingestion.

Boardflare Python executes in the browser runtime. User notebook code can make browser-compatible HTTP requests where the destination permits them. Normal browser security still applies, including CORS, origin rules, authentication design, and organizational network controls.

Which is better?

It depends on the security requirement.

Microsoft's inability to make arbitrary network requests is a security advantage when an organization wants workbook Python to be incapable of directly exfiltrating data.

Boardflare's browser networking is a capability advantage when an analysis legitimately needs a REST API or other CORS-compatible web service.

Do not reduce this to "local is safer" or "cloud is safer." They are different trust models.

12. Security and data boundary

Microsoft Python runs each workbook in its own hypervisor-isolated Microsoft Cloud container. Microsoft documents that:

• Python runs inside the organization's Microsoft 365 compliance boundary;
• data is not persisted in the Microsoft Cloud Python environment;
• the Python process cannot access the user's computer, devices, account, network, or user token;
• it cannot inspect workbook properties such as formulas, charts, PivotTables, macros, or VBA code beyond values explicitly referenced through supported interfaces;
• existing workbooks stay associated with an environment version until the user upgrades them.

That is a strong enterprise-managed isolation model.

Boardflare's normal notebook calculation happens client-side in the add-in's browser/Pyodide environment. The notebook is isolated from the parent Excel host by a cross-origin iframe and receives narrowly scoped capabilities for source persistence, workbook inputs, and output/function publication. Notebook source is persisted in workbook Custom XML after save and read-back verification.

Boardflare does not claim that App mode hides executable source from a determined workbook recipient. A workbook containing executable Python should be treated as executable content.

For the full Boardflare design, see Security and Data Flow.

13. Workbook access is constrained in both products—but differently

It is easy to assume that "Python in Excel" means Python receives an unrestricted Excel object model. Neither product uses that model for its primary notebook/calculation surface.

Microsoft explicitly prevents Python from inspecting arbitrary workbook formulas, charts, PivotTables, VBA, or macros. Python reads data through supported xl() references.

Boardflare similarly exposes explicit notebook capabilities rather than handing arbitrary Office.js access to Python. bf.inputs() defines data dependencies, while bf.publish() defines the values and callables exposed back to Excel.

The practical difference is in the supported bridge surface:

• Microsoft supports more Excel-native reference types such as images and Power Query connections.
• Boardflare adds a reactive input registry and explicit reusable-function publication.

14. Sharing and runtime availability

A workbook is only useful if the next user can calculate it.

Microsoft Python in Excel availability depends on platform, Microsoft 365 subscription, update channel, connected-experience policy, and—in some cases—whether premium compute or Manual/Partial calculation modes are required. Microsoft currently documents support across qualifying Windows, web, and Mac configurations, with mobile platforms excluded. See Python in Excel availability.

A Boardflare workbook that depends on notebook execution requires the Boardflare add-in. Notebook source and startup preference travel with the workbook, but live BF.OUTPUT and BF.FUNCTION calculation still require the runtime to start successfully.

When evaluating either option, test the second-user experience:

1. Send the workbook to a representative recipient.
2. Open it on the platforms the organization actually uses.
3. Recalculate it.
4. Confirm required sign-in/add-in/license behavior.
5. Confirm what stale or unavailable calculations look like.
6. Confirm what happens when external services or packages are unavailable.

15. Detailed scenario guide

A few lines of pandas analysis beside worksheet data

Likely fit: Microsoft Python in Excel.

If the calculation naturally belongs in one worksheet location and returning a DataFrame object or Excel spill is the goal, Microsoft's native PY surface is direct and requires no separate add-in programming model.

A large forecasting or financial model with substantial Python

Likely fit: evaluate Boardflare strongly.

A coherent notebook becomes increasingly useful as code grows to include imports, transformations, functions, diagnostics, scenario controls, explanations, charts, and output publication. The 200,000-byte source limit still needs to fit the application.

Python whose execution must not depend on worksheet tab order

Likely fit: Boardflare.

Microsoft intentionally uses workbook row-major calculation order. If Python structure should instead be determined by dependencies, a reactive notebook is the closer model.

Direct Python access to a Power Query connection

Likely fit: Microsoft Python in Excel.

xl() directly supports Power Query connections. Boardflare currently has no equivalent public notebook input type.

Reuse one Python algorithm in many ordinary worksheet formulas

Likely fit: Boardflare.

Publish the implementation once and call it with BF.FUNCTION(). Microsoft PY cannot be directly composed with other Excel functions as an ordinary UDF.

Keep DataFrames as worksheet-resident Python objects

Likely fit: Microsoft Python in Excel.

Python object cards are a native part of Microsoft's model. Boardflare keeps arbitrary Python objects in the notebook and publishes only Excel-compatible values.

Call a REST API from the Python analysis

Likely fit: Boardflare, if the service is browser-compatible.

Microsoft intentionally disables Python network access. Boardflare notebook requests remain subject to normal browser/CORS/authentication constraints.

Organizational policy requires Python to have no arbitrary network access

Likely fit: Microsoft Python in Excel.

The Microsoft cloud container deliberately blocks Python network access and local device access.

Python source must go through Git review

Likely fit: Boardflare.

The notebook can be downloaded/uploaded as Marimo .py source. Microsoft's code editor consolidates editing across cells, but Microsoft does not currently document a native whole-workbook .py export workflow.

External file-system automation, scheduled jobs, database pipelines, or unsupported native packages

Likely fit: neither.

Use an external Python environment when the workload is really system automation or a data pipeline that happens to consume or produce Excel workbooks.

16. Comparison matrix

Dimension	Microsoft Python in Excel	Boardflare Python for Excel	Why it matters
Primary Python artifact	PY cells across worksheets	One Marimo .py notebook	Code organization and review
Execution order	Row-major; includes worksheet order	Reactive dependency graph	Moving cells/sheets vs. dependency-driven execution
Recalculation	Python formulas sequentially recalculate after dependency changes	Affected reactive descendants rerun	Large-model semantics
Code editor	Task pane shows all Python cells by sheet/cell	Full Marimo notebook editor	Both support larger editing, but program models differ
Documented source limit	No Python-specific whole-program limit published	200,000 UTF-8 bytes	Large source planning
Whole-program .py export	Not documented as a native workflow	Built in	Git, backup, portability
Input API	xl()	bf.inputs() / bf.ref()	Dependency contract
Range conversion	DataFrame by default for arrays	DataFrame for multi-cell range	Similar default analytical shape
Power Query	Yes	No equivalent public input contract	External-data workflows
Image input	Yes	No equivalent public input contract	Image-analysis workflows
Generic Python object cell	Yes	No	Intermediate object workflows
Excel-compatible output	Yes	BF.OUTPUT()	Worksheet integration
Reusable Python worksheet function	PY is not a composable UDF	BF.FUNCTION()	Reusing one implementation across formulas
Network access	No	Browser-compatible networking	API integration vs. isolation
Local machine/device access	No	Browser sandbox; no arbitrary desktop Python access	Desktop automation is outside both core models
Runtime	Microsoft Cloud container	Browser/Pyodide WebAssembly	Trust, package, and deployment model
Packages	Microsoft/Anaconda curated environment	Pyodide-compatible ecosystem	Package compatibility
Microsoft 365 compliance boundary	Yes	Different add-in/browser architecture	Enterprise governance
Notebook UI controls	Worksheet-centric	Marimo reactive UI	Application-style analytical tools
App presentation mode	No equivalent notebook App mode	Open as: App	Repeatable end-user presentation
Input capacity headline	100 MB per Python calculation	100k cells/reference, 250k total, 512 KiB snapshot	Different protocol/runtime constraints
Published output limit	Governed by Excel/Python output behavior	100,000 cells per result	Large output planning
Recipient requirement	Eligible Microsoft 365 Python-in-Excel environment	Boardflare add-in/runtime	Deployment and sharing

17. What we deliberately do not claim

A technical comparison is only useful if uncertain facts are labeled as uncertain.

We do not claim PY has an 8,192-character Python limit

Excel documents an 8,192-character formula-content limit, and PY is represented as a formula for add-in/readback purposes. But Microsoft does not currently state that 8,192 characters is the supported Python-source maximum for a Python cell. The Python Code Editor is specifically designed for large code blocks. Treating the generic formula limit as a verified PY limit would therefore be stronger than the available documentation supports.

We do not infer performance from the calculation model

Reactive dependency execution can avoid unrelated notebook work; Microsoft's row-major Python model recalculates Python formulas sequentially. That architectural difference is real. It is not sufficient to claim that one runtime is always faster. Benchmark the actual workbook.

We do not claim browser execution is automatically more secure than cloud execution

Microsoft's container deliberately removes network, local-device, and token access and operates inside Microsoft's compliance framework. Boardflare keeps normal notebook computation client-side but permits browser networking and uses an add-in capability boundary. The correct security comparison is about trust boundaries and required capabilities, not a generic local-versus-cloud slogan.

18. How to evaluate both with your own workbook

For a serious deployment, build a small proof-of-concept around the behavior that matters rather than translating a generic demo.

Calculation semantics

• change one workbook input and observe exactly what reruns;
• move/reorder Python code and worksheets;
• reset/reopen the workbook and confirm state reconstruction;
• test the largest realistic model rather than a toy example.

Source lifecycle

• inspect how much Python is required;
• save, close, reopen, and recover the source;
• extract the source for code review;
• test merge/version-control workflows if they are required.

Data conversion

Test at least:

• number, text, Boolean, blank, and Excel error cells;
• dates and times;
• DataFrames and Series;
• NumPy arrays;
• missing values and NaN;
• very large integers and infinities;
• unsupported Python objects;
• large spills/results.

Environment and deployment

• confirm required packages;
• confirm network/API requirements;
• confirm Power Query or other external data paths;
• confirm recipient licensing/add-in availability;
• confirm organizational security and compliance requirements.

Official Microsoft references

The Microsoft side of this comparison is based primarily on:

• Get started with Python in Excel — calculation order, recalculation, xl() basics, output modes and external-data boundary.
• PY function — static source representation, supported reference types, return types and formula-composition restriction.
• Python in Excel code editor — workbook-wide code editing by worksheet and cell.
• Python in Excel initialization settings — default scalar/array conversion configuration and workbook-wide initialization.
• Python in Excel DataFrames — Python object cards and Excel-value output.
• Data security and Python in Excel — cloud isolation, network/device/token restrictions, workbook access and environment versioning.
• Open-source libraries and Python in Excel — managed package model.
• How to correct a #CALC! error — 100 MB per-calculation data boundary.
• Python in Excel availability — supported platforms, compute tiers and calculation-mode availability.
• Excel specifications and limits — general Excel formula limits, which are intentionally not presented here as a verified Python-specific PY source limit.

For Boardflare implementation details, continue with Architecture and Runtime, Security and Data Flow, and Working with Excel.