Annotations are enforced ¶

The most immediate departure from Python: in SPy, type annotations are enforced. Always. Running:

def main() -> None:
    x: int = "hello"

raises a real TypeError with a precise error message:

TypeError: mismatched types
  |     x: int = "hello"
  |              |_____| expected `i32`, got `str`

This is not a linter warning. It happens at runtime in interpreted mode and at compile time in compiled mode.

Static operator dispatch via redshifting ¶

SPy introduces redshifting — a compile-time partial evaluation pass that resolves all type-dependent operations before runtime. After redshifting, a + b for two integers becomes a direct call to i32_add ; for two strings it becomes str_add . The generic operator no longer exists at runtime.

This has a crucial consequence: a type mismatch like 1 + "hello" is caught at compile time, not at runtime, because the resolution of + is a @blue (compile-time) function that raises a TypeError when it cannot find a valid implementation for the given types.

Dynamic dispatch is opt-in ¶

In Python, everything is dynamic and you opt in to static typing. SPy inverts this. Code is statically typed by default. If you genuinely need dynamic dispatch, you annotate with the explicit dynamic type:

def add(x: dynamic, y: dynamic) -> dynamic:
    return x + y

The rationale, stated directly in the SPy documentation, is that dynamic dispatch “is costly and prevents many other optimizations.” Making it explicit makes the cost visible and intentional.

Metaprogramming is fully type-safe ¶

This is SPy’s most distinctive improvement over Python’s type situation. In Python, a make_adder factory that returns different function types depending on its argument will cause mypy to give up and return Any . In SPy, @blue functions are evaluated by the interpreter at compile time, with the concrete types fully known. The type checker is aware of this:

@blue
def make_adder(y: dynamic):
    T = type(y)
    def add(x: T) -> T:
        return x + y
    return add

add5 = make_adder(5)      # type: def(i32) -> i32  — fully known
add_w = make_adder(" w")  # type: def(str) -> str  — fully known

There is no Any leakage. The compiler knows the precise type of add5 and add_w because it evaluated make_adder itself. If you then write add5 + "hello" , you get a compile-time TypeError — adding a function and a string — with no special support needed.

This is a qualitative improvement over any Python type checker, not merely a quantitative one. The fundamental reason Python checkers fail here is architectural: they analyse code without running it. SPy’s @blue mechanism runs the metaprogramming code at compile time, which is why typechecking can follow it.

Compile-time errors are programmable ¶

Because type checking flows through the same @blue mechanism as everything else, library authors can raise StaticError from any @blue function to produce compile-time errors with domain-specific messages:

@blue.generic
def SmallString(size: int):
    if size > 32:
        raise StaticError("SmallString must be at most 32 chars")
    return str

def say_hello(name: SmallString[64]) -> None:  # fails at build time
    print(name)

This is a capability Python has no equivalent for.

Garbage collection instead of a borrow checker ¶

SPy’s memory model is explicitly two-level:

• Safe high-level code uses a garbage collector. Memory is managed automatically; lifetimes are not tracked by the type system.

• Low-level unsafe code uses manual allocation ( raw_alloc , raw_free ) with no borrow checker — essentially C with Python syntax.

This is the single largest divergence from Rust, and it is a conscious trade-off, not an oversight.

What is lost: Hard real-time guarantees are impossible with a GC, since collection pauses can occur at any time. SPy cannot target operating system kernels, embedded firmware, or hard real-time audio pipelines — Rust’s home territory.

What is gained: The borrow checker is Rust’s steepest learning curve by far. By using a GC, SPy remains approachable to Python programmers. It also makes Python interoperability far simpler, since CPython objects are themselves GC-managed.

The honest scope: The workloads where a GC is disqualifying are also workloads where Python-like ergonomics would feel alien. SPy is not trying to replace Rust in Rust’s home territory. For server software, scientific computing, data pipelines, and most application code, a well-implemented GC is entirely adequate — as Go has demonstrated.

No borrow checker in unsafe code either ¶

In unsafe SPy, the programmer is responsible for avoiding use-after-free and out-of-bounds access. The interpreter and debug compiled mode add runtime bounds checks (pointers track their array length as a fat pointer). Release mode strips these checks and emits plain C pointers — exactly as fast as C, and exactly as unguarded.

The CPython parallel is intentional: CPython’s C internals are unsafe, yet most Python users never touch them. SPy’s unsafe layer is for library authors, not end users.

Algebraic data types ¶

Python 3.10 introduced match statements and union types ( int | str | None ). The concept is already in the Python vocabulary. The question for SPy is whether to enforce exhaustive matching statically — and this hinges on a single design decision: whether None should be opt-in rather than universally valid.

In Rust, you cannot use a value that might be None without pattern matching it first, because there is no implicit null. If SPy made nullability explicit — only int | None can be None , not bare int — then the static enforcement of pattern matching would provide real safety guarantees. This would be a meaningful break from Python semantics, but SPy already accepts breaking compatibility where the benefit is clear.

ADTs are compatible with having a GC : they are purely a type-system feature. Haskell has one of the most powerful ADT systems of any language, and it is garbage-collected.

The main design question is cultural: Python programmers are accustomed to None appearing anywhere. Making it opt-in would take adjustment. But it is technically clean and would eliminate a large category of AttributeError: 'NoneType' object has no attribute '...' bugs that Python programmers encounter daily.

Traits as structural protocols ¶

Python already has typing.Protocol (PEP 544): a structural interface mechanism that type checkers understand. This is the natural SPy equivalent of Rust traits, and it would be far more Pythonic than Rust’s trait syntax.

SPy’s @blue operator dispatch already implicitly checks trait-like constraints. If you pass a type to a generic @blue function and that type does not support the required operations, you get a StaticError at compile time. What is missing is the ability to declare the constraint upfront:

# Hypothetical SPy syntax, following Python's Protocol
from typing import Protocol

class Addable(Protocol):
    def __add__(self, other: Self) -> Self: ...

@blue.generic
def add(T: type[Addable]):  # constraint declared, not discovered
    def impl(a: T, b: T) -> T:
        return a + b
    return impl

The benefit is twofold: the API is self-documenting, and errors surface at the call site with a clear message (“T does not implement Addable”) rather than somewhere inside the function body.

The full Rust trait system — with associated types, blanket implementations, trait objects, and the orphan rule — would be both overkill and un-Pythonic. But a lightweight Protocol -based constraint system would fit SPy naturally and significantly improve the library authoring experience.

Crucially, like ADTs, traits are orthogonal to memory management . A GC-based language can have an excellent trait/protocol system.