Boardflare Python for Excel vs. Microsoft Python in Excel

A detailed technical comparison of Boardflare Python for Excel and Microsoft Python in Excel, including calculation order, source storage, type conversion, limits, packages, security, interoperability, and the scenarios where those differences matter.

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.

NoteVerification date

Microsoft behavior on this page was checked against Microsoft’s public documentation and the executable Excel compatibility harness on August 17, 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.

flowchart LR
    subgraph S1[Sheet 1]
        A1[PY A1] --> B1[PY B1] --> C1[PY C1]
        C1 --> A2[PY A2]
        A2 --> B2[PY B2] --> C2[PY C2]
    end
    C2 --> D1
    subgraph S2[Sheet 2]
        D1[PY A1] --> E1[PY B1] --> F1[PY C1]
    end

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.

flowchart TD
    Input[Workbook input] --> Clean[clean_data]
    Clean --> Forecast[forecast]
    Clean --> QA[validation_checks]
    Forecast --> Summary[summary]
    QA --> Summary
    Summary --> Output[BF.OUTPUT]
    Forecast --> Fn[BF.FUNCTION]

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.

flowchart LR
    WB[Excel workbook] -->|open| NB[Marimo notebook]
    NB -->|Save| XML[Workbook Custom XML]
    NB -->|Download| PY[notebook.py]
    PY --> Git[Git / diff / review / backup]
    PY -->|Upload| Staged[Staged replacement]
    Staged -->|Marimo Save| XML

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 aligned with the default xl() behavior verified by the executable compatibility harness for ordinary workbook values:

Excel reference/value Boardflare Python value
Truly blank cell None
Formula / explicit empty text ""
Numeric / Boolean / text cell corresponding Python scalar
Date / datetime / time formatted cell corresponding Python datetime / time value
Worksheet error typed ExcelErrorValue, intentionally inspectable rather than immediately propagated
Multiple cells pandas DataFrame; text/date dtypes normalized to the observed xl() behavior
Multiple cells with headers=True DataFrame using the first row as columns

The typed Excel-error value is the principal ordinary-input difference: Microsoft xl() propagates the scalar error through the PY calculation, while Boardflare keeps the error distinguishable from literal text such as "#N/A" so reactive notebook code can inspect or republish it. See Excel ↔︎ Python type conversion for the exact scalar and range cases.

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 the Excel-value conversion contract validated by the compatibility harness. The high-value cases are:

Python value Boardflare worksheet result
str, bool, safe int, finite float Corresponding Excel scalar
None Excel value displayed as None
NaN, positive/negative infinity #NUM!
pd.NA #N/A
pd.NaT #NUM!
complex scalar #N/A
date, naive datetime, time Formatted Excel date/time value
timezone-aware date/time #VALUE!
timedelta Excel day fraction
1-D list / tuple / NumPy array Vertical spill
rectangular 2-D value Rectangular spill
ragged 2-D sequence Padded with #N/A
pandas Series One column; name becomes a heading when present
pandas DataFrame Column headings included; index included when named or nonnumeric
NumPy 0-D ndarray #VALUE!
NumPy 3-D+ ndarray First two dimensions spill as a grid of #VALUE! cells
Integer outside ±9,007,199,254,740,991 Rejected rather than silently rounded
set Rejected because worksheet order would be nondeterministic
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 input conversion hooks through its initialization settings and allows a PY result to be returned either as Excel values or as a Python object. Boardflare fixes the notebook input/output contract and targets Microsoft’s Excel-value behavior rather than its Python-object-card mechanism.

Case Microsoft Python in Excel Boardflare
Truly blank Excel cell → Python None in the harness None
Explicit/formula empty text → Python "" ""
Date/time Excel cell → Python Python date/time value Same target behavior
Scalar worksheet error → Python Propagates through PY probe Typed ExcelErrorValue so the notebook can inspect/round-trip it
Multi-cell range → Python pandas DataFrame by default pandas DataFrame
Header handling xl(..., headers=True) bf.ref(..., headers=True)
DataFrame → worksheet values Headings/index layout verified by harness Same Excel-value layout
1-D sequence / ndarray Vertical spill in harness Vertical spill
Ragged 2-D sequence #N/A padding in harness Same
None → Excel value displayed as None in harness Same display behavior
NaN / ±infinity #NUM! in harness #NUM!
pd.NA / pd.NaT #N/A / #NUM! in harness Same
timezone-aware datetime #VALUE! in harness #VALUE!
very large integer Can cross into Excel’s finite-precision number representation Rejected outside exact ±(2^53−1) range
Python object card Supported with return_type=1 Not emulated by BF.OUTPUT; publish Excel-compatible values instead

The detailed edge cases in this table are empirical results from the executable workbook, not claims that Microsoft’s Support pages permanently specify each exact mapping. Download and run the Excel ↔︎ Python type-conversion harness or see the maintained type-conversion reference when a particular boundary matters to a workbook.

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.

Boardflare’s two intentional safety differences are also material in sensitive workbooks: integers outside Excel/JavaScript’s exact range are rejected rather than silently rounded, and unordered sets are rejected rather than producing an unstable spill order.

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)

flowchart LR
    A[Worksheet arguments] --> F[BF.FUNCTION]
    F --> R[Running notebook]
    R --> P[Published Python callable]
    P --> V[Converted Excel result]
    V --> F

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.

flowchart TD
    subgraph M[Microsoft Python in Excel]
        MX[Excel / Power Query] --> MC[Microsoft Cloud Python container]
        MC -.-|no arbitrary network| Block[External network blocked]
    end

    subgraph B[Boardflare]
        BX[Excel workbook inputs] --> BP[Browser / Pyodide notebook]
        BP -->|browser-compatible HTTP| API[External API]
        API -->|subject to CORS / auth| BP
    end

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:

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