POST Python

Skip to content

Initializing search

openteams-ai/postpython

Getting Started

Specification

Toolchain & C ABI

Distribution Policy

PostSciPy Roadmap

POST Python¶

Performance Optimized Statically Typed Python — a defined, compilable<br>subset of Python with a normative specification and a reference<br>ahead-of-time compiler.

A POST Python source file is valid Python. It runs unmodified under the<br>standard CPython interpreter — and a conforming compiler translates the<br>same file to native code with no Python runtime in the binary.

from postyp import Float64<br>from postpyc import vectorize<br>from postpyc.math import exp

@vectorize<br>def gaussian(x: Float64, mu: Float64, sigma: Float64) -> Float64:<br>"""Normal probability density."""<br>z: Float64 = (x - mu) / sigma<br>return exp(-0.5 * z * z) / (sigma * 2.5066282746310002)

That one definition is, today:

an interpreted Python function — callable immediately, NumPy<br>broadcasting included;

a native C kernel — post-py build emits C99, compiles each<br>module as its own translation unit, and links a shared library with a<br>stable C ABI: pp_gaussian callable from C, Rust,<br>Julia, R, or ctypes;

a real numpy.ufunc — post-py build --ext-module produces an<br>importable CPython extension with full broadcasting, out=, dtype<br>handling, and the original docstring.

One code base. One artifact per audience. No vendored binaries.

Why a standard, not just a compiler&para;

Python has many compilation projects — Cython, mypyc, Numba, Codon,<br>Pythran, taichi — each defining its own informal subset. POST Python<br>inverts that: the specification is normative, organized into<br>conformance profiles (POST Core, POST Array, POST Ufunc ABI, CPython<br>Extension, …), and the compiler in this repository is a reference<br>implementation, not the definition. Existing tools are invited to claim<br>conformance for the profiles they support.

The reference implementation follows one cardinal rule: reject<br>unsupported semantics clearly rather than accepting code and changing<br>behavior. Valid-but-unimplemented POST Python produces an explicit<br>diagnostic, never a silent rewrite.

Proving ground: rebuilding SciPy&para;

The primary way the language and compiler grow is the<br>PostSciPy effort — recreating SciPy one subpackage at a<br>time as pure POST Python libraries<br>(ppspecial for<br>scipy.special, with thirteen more pp* packages scaffolded). Real<br>numerical code discovers what the language is missing; those gaps become<br>compiler and specification work.

ppspecial today: 26 special functions (error functions, gamma family,<br>Bessel, statistical) — every module compiles natively, cross-module calls<br>link per the spec's translation-unit model, and the whole package builds<br>into a single library and an importable NumPy extension.

Status&para;

POST Python is early and moving fast. Working today in the reference<br>implementation:

Area<br>State

Structural checker (subset enforcement, PP0xx diagnostics)

Scalar kernels, control flow, module constants

@vectorize / @guvectorize with NumPy-conformant gufunc ABI

Cross-module compilation and linking (one object per translation unit)

CPython extension-module output (real numpy.ufunc registration)

Stable C ABI: pp_* exports, generated headers, export manifests

Structs, executables, callable parameters, local array allocation<br>🔜 spec'd, not yet lowered

The specification is a v0.2 draft . Interfaces will change.

Where to go next&para;

Getting started — install, write a kernel,<br>compile it three ways.

The specification — the normative document.

Toolchain & C ABI — the CLI, headers, and manifests.

Distribution policy — source-only PyPI; binaries<br>through package managers that treat native code honestly.

Back to top

Made with

Material for MkDocs