SPy: My Recent Contributions and What's Coming

SPy is a new programming language created by Antonio Cuni, and I’m convinced it could play a significant role for the Python community in the coming years.

Over the past few months, I’ve invested a lot of time and energy into SPy — building demos, improving the project, and developing a deep understanding of both the language and its implementation. This work is captured in a Jupyter Book I’ve been assembling on SPy . I’m also presenting SPy and related technological questions about Python at the JDEV conference in Montpellier this June. It feels like the right moment to write up a summary of what I’ve been doing.

Demos

Demos are vital for a young project like SPy: they make it tangible, attract attention, and can bring in contributors.

Antonio Cuni already produced a striking demo of SPy running on AWS Lambda , showing that SPy can serve web requests with Python-like ergonomics while matching the startup time and performance of Go or Rust. I’ve been working on two complementary demos exploring quite different aspects of the language.

Web Applications with SPy — JSFFI

This directory contains browser demos showing how SPy/WASM can drive a webpage interactively — including 60fps canvas animations — without PyScript, Pyodide, or any hand-written JavaScript logic. The only JS present is the small Emscripten bootstrap generated automatically by the SPy compiler.

The HTML pages are generated with FastHTML and Python (Tailwind/DaisyUI for styling). The dynamic part — simulation, rendering, event handling — is entirely written in SPy and compiled to WebAssembly with Emscripten.

Two demos are available:

  • image_data — a colour animation driven by RGB sliders, rendered via putImageData into a canvas pixel buffer.

  • particles — a 60fps bouncing particle simulation using the canvas 2D API ( arc , fillRect , createRadialGradient ), with controls for particle count, speed, and radius.

In release mode ( RELEASE=1 ) the compiled binaries are remarkably small: the .wasm file is around 27 KB and the Emscripten glue .mjs around 64 KB , for a total of roughly 91 KB — smaller than a typical webpage image, and orders of magnitude smaller than a PyScript/Pyodide deployment (~10 MB).

  • Issue #483 : Add primitives needed for 60 fps canvas demos driven purely from SPy

  • PR #484 : Web without PyScript and JS

Source: paugier/spy — web-without-pyscript-js

Live demos:

Loop Fusion with SPy

Source: paugier/spy-demos — loop-fusion

This demo is more technical, and closer to my own research interests. It’s about implementing minimal array libraries (à la NumPy) with loop fusion — an optimization where multiple operations over an array are merged into a single pass, avoiding intermediate allocations and enabling the C compiler to use SIMD instructions . The same technique is used, for example, in Pythran with C++ expression templates.

The demo shows how a SPy library can let users write expressions like x + sin(x) (with x an array) and get a single fused loop under the hood, as described in my SPy Book .

To finalize this demo, we need a @force_inline decorator. I opened PR #467 with a minimal implementation, but Antonio has since reimplemented it more robustly in PR #504 , which already unlocked the first practical payoff: support for multi-argument print() in PR #510 . The loop-fusion demo can now be finalized on top of this stronger foundation.

Where Things Stand

Both demos are working, but neither is ready to communicate about publicly. Together, they illustrate SPy’s potential for Python developers — and also highlight the features still needed before SPy can be used comfortably for such tasks (notably an unroll function and *args support for red functions).

Pull Requests

Merged

  • PR #418 : playground: myarray.spy, fix gc_alloc + blue.generic

  • PR #430 : cli: fix cdump (should not compile)

  • PR #437 : Type parameter syntax (PEP 695) with generic_args in FuncDef

  • PR #452 : str: add __repr__

  • PR #466 : Fix method call for metafunc

  • PR #480 : Support isolated module-level str

  • PR #489 : Fix bug in setattr register

Ready or nearly ready

  • PR #448 : Generic types (syntactic sugar for blue.generic)

    I also care about type and __blue_checks__ described in this comment .

  • PR #462 : Implement hasattr (blue arg)

  • PR #471 : Abs as a metafunc in stdlib to support more types

  • PR #477 : Show a simple Pixi setup

  • PR #481 : Move .spy playground files into examples and test all examples

  • PR #488 : Fix var NULL ptr global and tests

Have been superseded

  • PR #467 : @force_inline (minimal version, superseded by Antonio’s PR #504 )

  • PR #434 : io: implement posix.open/read/write/close + _io.FileIO + open

Draft

Future and personal aspects

SPy resonates with me personally because it addresses needs I’ve had for a long time as a Python user. I’m exactly the kind of developer who needs something like SPy or Mojo: a language that stays close to Python while unlocking the kind of performance that typically requires dropping down to C or Rust. What makes SPy compelling even compared to Mojo — which is far more mature and backed by substantial investment from Modular — is that it is closer to Python, fully open-source, and built on relatively approachable technologies. Advanced Python users can contribute to SPy and develop a genuine understanding of how it works.

The immediate priority is to finish the technical work already underway, but it’s equally important for me not to remain purely at that level.

As a researcher, I need to accompany the demos with abstracts, conference presentations, and written articles. I plan to work on SPy documentation alongside my presentation at JDEV in June, and I’d also like to submit an abstract for the Compute! conference in Paris.

Open Issues

unroll , f-strings and *args for red functions are other future planed developments very important for me.

Funding and a “Faster Python” umbrella project

I’d like to spend more time on SPy and see it succeed — but as a CNRS researcher, a significant thematic shift like this requires a proper funded project where I play a central role, with resources for my lab. That’s simply how the system works: without it, I can contribute on the margins but not at the level this deserves. And beyond my own time, meaningful progress on the SPy/scientific Python front requires dedicated workforce — typically a full-time developer and a PhD student. So finding the right funding vehicle is not a secondary concern; it’s a prerequisite for everything else in this section.

Beyond my own needs, I also want to help improve the funding landscape for projects aiming to fix Python’s performance underpinnings more broadly.

A new Faster Python umbrella project

I think it would be valuable to create a broader Faster Python umbrella project: an initiative to bring together people and projects that share an interest in improving Python’s foundations, even when approaching the problem from different angles. This would include, for instance:

There are already discussions between some of these groups, but the conversations remain informal and fragmented. Yet they share deep technical concerns — stable ABIs, efficient interop, JIT-friendly object models, ahead-of-time compilation. An umbrella project could serve several purposes: fostering cross-project dialogue, producing a shared description of the technical landscape and goals, and — crucially — giving people seeking funding a clearer story to tell. A well-framed collective vision is much easier to pitch to funding agencies than any single niche project in isolation.

I’ll be reaching out to people who might be interested. If that’s you, get in touch!

A small group working on SPy in Grenoble

On the SPy side specifically, it would be very valuable to build a small group in Grenoble focused on the needs of the scientific Python community, and more particularly the fluid mechanics community.

The overall goal would be to improve SPy to the point where, within a few years, it becomes (i) a better Pythran, (ii) a better Cython — both for wrapping C libraries and writing numerical kernels — and (iii) a better RPython for implementing interpreters, as PyPy. SPy could also become a compelling alternative to MicroPython and Pyodide/PyScript in certain contexts. The potential impact on the broader Python ecosystem is laid out in my note SPy: a vision for its impact on the Python community .

I envision this as a three-year project — aligned with a PhD thesis in France — carried out in close collaboration with Antonio Cuni and the SPy community, as well as with PyPy and NumPy developers and others involved in the Faster Python umbrella.

Concretely, I’d like to build a small team in my lab around SPy, combining a full-time developer and a PhD student. A first shared task would be completing SPy’s roadmap, particularly the language core and SPy/C integration.

Our specific contribution from Grenoble would focus on developing NumSPy : an efficient SPy implementation of the Python array API standard (see the dedicated section in my vision note ).

A further axis would depend on whether the Python Native Interface (Py-NI) is formally adopted into CPython — possibly in Python 3.16 or 3.17. If so, a key goal would be to ensure NumSPy is usable by other projects through Py-NI, making it a genuine building block for the ecosystem.

The central practical question is how to secure funding for this group. This represents a significant commitment — around 150–200 k€ over three years — and a real thematic shift for me, so it is not a trivial matter. Identifying the right funding instruments and the right partners will be one of my main priorities over the coming months.