Improving the Python Developer Experience: Workflows for Debugging, Inspection, and Formulas

Developers
1

Hi everyone,

I want to bring a specific topic to the fore, as it’s something I’m actively grappling with.

I am a Python developer, and I frequently help partners get the most out of Grist. While my goal is always to leverage as much built-in functionality as possible, I often find myself writing small, custom functionalities within Python formulas to achieve the best UX/ergonomics for our workflows.

However, I highly miss having a robust environment to support this kind of development. Coming from a traditional Python background, I heavily rely on two types of workflows:

  1. The IDE: Where I value autocompletion, real-time inspection, and step-by-step debugging.

  2. Reactive Notebooks (like Marimo): Where I value easy inspection of cell scopes, states, and variables.

In my exploration of Grist, I couldn’t quite figure out the underlying architecture of the SaaS version (e.g., whether it’s running Python 3.11 via Pyodide, standard CPython, or something else). Because of this sandbox environment, I haven’t found a way to plug into the Python interpreter to output debugging messages, inspect available variables, or step through formula execution.

I would love to hear from the wider community and the Grist team on a few points:

  • Current Workarounds: What approaches do you use to debug and inspect complex Python formulas right now? Are there hidden tricks for surfacing logs or state?

  • Roadmap Updates: Is there anything on the roadmap to improve the DX (developer experience) for writing Python within Grist, such as advanced autocomplete or integrated debugging tools?

  • Formulas vs. Custom Widgets: Is the general philosophy to keep formulas lightweight and instead lean on Custom Widgets for more complex, logic-heavy functionalities? If so, what does that workflow look like in practice for you?

Looking forward to hearing your thoughts and experiences!

2 Likes
2

This should help answer one of your questions.

In my Grist Desktop installation, I found the following folder:

C:\Program Files\Grist Desktop\resources\app.asar.unpacked\core\sandbox\pyodide

3

Thanks @Phil_Colbert .

I can tell from using the Chrome DevTools that there is a persistent websocket connection to a service called docworkerthat receives each update I do on the document, and sends me changes other instances of the page do on the same document.
And what formulas do also… so the formulas seem to be executing on the cloud.
Would be good to know.
Thanks for chiming in!

4

well, a couple old Python tricks still work in Grist Saas – calling globals() and locals(), importing “inspect” and “traceback”… maybe one could hack a custom debugger widget to show some internals? Or maybe someone already did it…

1 Like
5

I’m pretty sure the Grist SaaS uses a fully fledged python interpreter in a gVisor sandbox. For self-hosted, this can be configured, too, though pyodide seems to be the default. So, @Nico_Pace, yes I’d say python runs in the cloud. There’s an RPC bridge between the python interpreter and the NodeJS server.