RFC: burn-python — A PyO3-based Python frontend for Burn

[asjad2401]

Summary

I'd like to propose and potentially build burn-python — a PyO3-based Python package that gives Python users access to Burn's tensor engine and model inference without writing any Rust.

Motivation

Burn is the most capable Rust DL framework available, but it's completely inaccessible to the Python ML community. There is no pip install burn, no import burn, no way to run a Burn-trained model from Python today.

Issue #4411 shows a real user struggling to pass numpy arrays to Burn tensors efficiently.
A maintainer documented the zero-copy path using bytes::Bytes + TensorData — but that solution requires users to write non-trivial unsafe Rust. A Python library would make this invisible.

Proposed scope (incremental)

Stage 1 — numpy ↔ Burn tensor bridge

Zero-copy conversion between numpy arrays and Burn tensors using PyO3 +
rust-numpy, following the pattern documented in #4411.

import burn_python as burn
import numpy as np 

x = np.random.randn(32, 128).astype(np.float32)
t = burn.tensor(x, backend="ndarray")  # zero-copy
arr = t.numpy()                         # back to numpy

Stage 2 — Python inference API

Load ONNX or safetensors models and run inference from Python:

model = burn.load_onnx("resnet50.onnx", backend="wgpu")
output = model(x) # returns numpy array

Stage 3 — Python training API (longer term)

Define models and training loops in Python, backed by Burn's autograd engine.

Questions for maintainers

1. Is this something the Burn project would welcome as a first-party crate (crates/burn-python) or would it be better as a separate community repo?
2. Are there any existing efforts in this direction I'm not aware of?
3. For Stage 1, is bytes::Bytes + TensorData::from_bytes still the recommended zero-copy path, or has this changed recently?
4. Any guidance on which backend to target first for the Python bridge?

My background

I've been building rustnum — a NumPy-compatible Python library backed by Rust via PyO3 — and recently contributed a fix to rust-numpy (PyO3/rust-numpy#550). I'm familiar with the PyO3 + rust-numpy stack and looking for a larger contribution to make in the Rust ML ecosystem.

---

[nathanielsimard]

Thanks for the suggestion. There is no active work in that direction, but it's not something we're against. I was always worried about having both a Rust and a Python frontend for Burn. But having it scoped to ONNX model inference is good. We don't have to duplicate the neural network ecosystem and split the community work, but having an easy interop with a small API surface for Python can be good.

For now, I believe this is better handled by a community repository. There would be too many PRs to review at the beginning to set up the project, and the rate at which we iterate on Burn isn't the same as for a newly defined project. If the community project proves itself, we may be open to maintaining it as part of Tracel's ecosystem.

[asjad2401]

Thank you for the clear direction. I'll start a community repository scoped to ONNX model inference from Python - numpy in, numpy out, minimal API surface. I'll share it here once there's something worth showing.