[feature] Python bindings via PyO3

[martinadamsdev]

Summary

Would there be interest in Python bindings for casbin-rs using PyO3?

Motivation

• The existing pure-Python pycasbin works well, but a Rust-backed binding would offer significantly better enforcement throughput for high-traffic services.
• PyO3 + maturin makes it straightforward to publish a pip install-able wheel to PyPI.
• Other Rust projects (e.g., pydantic-core, ruff, polars) have demonstrated this pattern successfully.

Rough Scope

1. A PyO3 wrapper around the core casbin API — Enforcer, model/policy loading, enforce(), RBAC role management.
2. Publish to PyPI with pre-built wheels for Linux / macOS / Windows via maturin + GitHub Actions.

Questions for the Community

• Is this something people would find useful?
• Should it live in this repo (as a workspace crate) or in a separate repo?
• Which subset of the API would be most valuable to expose first?
• Anyone interested in collaborating on this?

[hsluoyz]

@martinadamsdev

Thanks for the well-structured proposal — this is a direction we're interested in. Answering your four questions, then raising the two design points that I think decide whether this succeeds.

1. Is it useful?

Yes. enforce() is the hot path for most users, and for large policy sets pure-Python pycasbin is dominated by matcher evaluation and policy iteration. Moving that into Rust is a real, order-of-magnitude-class win. Before we commit, though, I'd like to see a benchmark against pycasbin on a realistic workload (e.g. RBAC with role hierarchy, ~10k policies, ~100k enforce() calls) so we're arguing from numbers rather than from analogy with polars/ruff.

2. Which repo?

A separate repo, not casbin-rs. The casbin crate is a plain library and should stay dependency-clean; PyO3 pulls in the CPython ABI and pins a very different CI/release story (cibuildwheel matrix, abi3, PyPI trusted publishing) from cargo publish. Keeping them separate also lets the binding pin a released casbin version instead of tracking master.

Also note the PyPI name casbin is already taken by pycasbin, so the package will need its own name.

3. Which APIs first?

Roughly in this order:

• CoreApi: new_enforcer, enforce, enforce_mut, load_policy, save_policy, enable_auto_save, enable_enforce
• Model/policy loading: from file paths and from strings (FileAdapter, MemoryAdapter, StringAdapter)
• ManagementApi: add_policy / add_policies / remove_policy / remove_filtered_policy / get_policy / get_filtered_policy and the g-rule equivalents
• RbacApi: add_role_for_user, delete_role_for_user, get_roles_for_user, get_users_for_role, has_role_for_user, get_implicit_*
• Then the optional features that matter in production: cached (CachedEnforcer), glob, ip, explain

Watcher, RoleManager and custom matcher functions can come later — see below for why they're the tricky ones.

4. Interested in collaborating?

Yes, but I'd like a short design note (or a PoC branch) on the two points below before we bless a repo under the org, because they determine how much of the promised speedup actually survives.

---

Design point A — the async boundary

casbin-rs is async where the adapter is involved and sync where it isn't:

• Enforcer::new and load_policy are async (src/enforcer.rs:528, src/enforcer.rs:817)
• enforce / enforce_mut are sync (src/enforcer.rs:673, src/enforcer.rs:773)
• the Adapter trait is fully async (src/adapter/mod.rs:26)

So the binding has to decide: drive a private Tokio runtime and block_on inside the constructor and policy-mutating calls, giving Python a fully sync API that mirrors pycasbin; or expose async def via pyo3-async-runtimes. My recommendation is sync-first — it's what pycasbin users expect and what makes the binding a drop-in — with an async API considered later. Whichever you pick, enforce() should release the GIL (Python::allow_threads) so multi-threaded servers get true parallelism; that's a second, less obvious win over pycasbin that's worth designing in from the start.

Design point B — the adapter ecosystem (the make-or-break one)

A large share of pycasbin's value isn't the enforcer, it's the adapter ecosystem: SQLAlchemy, Django ORM, MongoDB, Redis, and so on. A Rust-core enforcer can't use any of them for free, and this is the part the proposal doesn't address.

Two options:

1. Rust adapters only. Fastest and simplest, but users have to give up their existing storage integration — which is exactly the reason most of them adopted pycasbin. This makes the binding a niche tool.
2. Bridge Python adapters into the Rust Adapter trait. A Rust shim implements Adapter and calls back into a Python object under the GIL. Users keep every existing pycasbin adapter, and — importantly — the callbacks land on load_policy / save_policy / add_policy, which are startup or write-path operations, while enforce() stays 100% Rust. That's the right place to pay the cost.

I'd go with (2), and treat (1) as an optimization for users who don't need the ecosystem.

The same GIL-callback question applies to Watcher, custom RoleManager implementations, and custom matcher functions. Custom functions are the one case where the answer should probably be "don't": a Python function called from the Rhai matcher on every request would run once per policy rule per enforce() call and would erase the speedup. If they're supported at all, that cost needs to be documented loudly.

---

If you're up for it, a PoC covering new_enforcer + enforce + a Python-implemented adapter, with a benchmark against pycasbin, would be enough to settle both questions and decide whether we move it under the org.