The problem ¶

Python’s dominance in scientific computing and data science rests on a fragile foundation: performance-critical code is written in C, C++, or Fortran and wrapped with Python bindings. This two-language wall has deep consequences. It limits who can contribute to core libraries (you need to know C, not just Python). It constrains alternative runtimes like PyPy and GraalPy from gaining adoption, because so much of the ecosystem depends on CPython-specific extension mechanisms. It also constrains CPython’s own JIT compiler: meaningful internal optimizations are blocked by assumptions the Python C API currently makes public.

Existing tools each address pieces of the problem but none fully solves it. Cython stays in the Python world but is a hybrid language with no interpreter, poor debugging, and no standalone output. Julia and Mojo solve performance elegantly but require leaving the Python ecosystem entirely. SPy takes a different path: a proper independent language that looks and feels like Python, with a clean compilation pipeline, an interpreter for interactive development, and a debugger ( spdb ) that works at the SPy level rather than dropping you into C.

How SPy works: two levels, blue and red, redshifting ¶

SPy is designed with two distinct levels of use, which is key to understanding both its power and its accessibility.

At the user level , SPy looks like ordinary typed Python. A user writing a simulation, a web handler, or an array expression does not need to know anything about the compiler internals — they write Python with type annotations, run it in the interpreter during development, and compile it when they need performance. This is the level that matters for the majority of Python developers.

At the library level , SPy exposes a powerful metaprogramming system centred on the notion of metafuncs and the distinction between blue and red expressions. Blue expressions are those whose value is known at compile time; functions can also be explicitly marked @blue , in which case they are guaranteed to be called during redshifting rather than at runtime. Red expressions must be evaluated at runtime. During a phase called redshifting , SPy eagerly evaluates all blue subtrees, replacing them with constants and eliminating dispatch logic before any code runs.

This is more than constant folding. A metafunc is a @blue function that runs entirely at compile time and returns a concrete implementation specialized for the types at hand. For example, the + operator on arrays is implemented as a metafunc: when the compiler sees x + sin(x) (with x an array), the metafunc is called at compile time and returns C code that fuses both operations into a single SIMD-friendly loop, with no intermediate allocation. The user writes Python; the compiler produces something a C developer would have written by hand.

This two-level design — familiar Python on the surface, principled metaprogramming underneath — is what allows SPy to be both approachable for library users and genuinely expressive for library developers.

WebAssembly as a first-class target ¶

WASM is not an afterthought in SPy: it is a first-class compilation target alongside native code. This unlocks deployment scenarios that are simply unavailable in the rest of the Python ecosystem: browser execution without PyScript or Pyodide, AWS Lambda cold starts comparable to Go, sandboxed execution, and distribution as a self-contained binary with no Python runtime dependency. The demos below make this concrete.

SPy in action: three demos ¶

AWS Lambda (demo by Antonio Cuni) : SPy serving web requests with Python-like ergonomics, matching Go in startup time and performance. A direct demonstration of what SPy-compiled WASM looks like in production.

Web without PyScript (Pierre Augier) : A 60 fps bouncing-particle simulation rendered in a browser canvas, driven entirely from SPy compiled to WebAssembly — no PyScript, no Pyodide, no hand-written JavaScript. Total binary footprint: ~91 KB (27 KB .wasm + 64 KB Emscripten glue), versus ~10 MB for an equivalent PyScript deployment.

Loop fusion (Pierre Augier) : A minimal array library written in SPy where expressions like x + sin(x) compile to a single fused C loop via metafuncs, with no intermediate allocations and SIMD-ready output — the same technique used in Pythran via C++ expression templates, but written in Python.

The vision ¶

A mature SPy could become several things at once for the Python ecosystem:

• A better Cython : writing numerical kernels and wrapping C libraries in genuine Python, with an interpreter, a debugger, and no hybrid syntax.

• NumSPy : a reimplementation of the Python Array API standard written in Python + SPy, readable by any Python developer, compatible with future runtimes via the Python Native Interface , and enabling whole-program optimisation when compiled end-to-end.

• Native entry points : Python CLI tools and services compiled to self-contained binaries with Go-like startup time.

• A better RPython : a platform for writing language runtimes and interpreters in something that genuinely looks and feels like Python — with meta-tracing JIT potential.

Structure and timing ¶

Target audience ¶

Python package maintainers, scientific Python users, and anyone interested in Python’s long-term performance story. No prior knowledge of compilers or type theory is required — the talk is grounded in practical demos motivated by real-world problems. Familiarity with NumPy or similar libraries is helpful context for the vision section.

Takeaway ¶

Attendees will leave with a clear picture of what SPy is, why it matters for the Python ecosystem, and how they can try it today — including pointers to the repository, the online playground , and open issues suitable for first contributors. The talk will also serve as an invitation to join the effort: SPy is mostly written in Python, and the community is welcoming.

Background knowledge required ¶

Basic familiarity with Python. No knowledge of compilers, WebAssembly, or C required.