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.