You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@casbin.apache.org by "martinadamsdev (via GitHub)" <gi...@apache.org> on 2026/03/22 16:27:30 UTC
[I] [feature] Python bindings via PyO3 [casbin-rs]
martinadamsdev opened a new issue, #418:
URL: https://github.com/apache/casbin-rs/issues/418
## Summary
Would there be interest in Python bindings for casbin-rs using [PyO3](https://github.com/PyO3/pyo3)?
## Motivation
- The existing pure-Python [pycasbin](https://github.com/casbin/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?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For additional commands, e-mail: commits-help@casbin.apache.org
Re: [I] [feature] Python bindings via PyO3 [casbin-rs]
Posted by "hsluoyz (via GitHub)" <gi...@apache.org>.
hsluoyz closed issue #418: [feature] Python bindings via PyO3
URL: https://github.com/apache/casbin-rs/issues/418
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For additional commands, e-mail: commits-help@casbin.apache.org
Re: [I] [feature] Python bindings via PyO3 [casbin-rs]
Posted by "hsluoyz (via GitHub)" <gi...@apache.org>.
hsluoyz commented on issue #418:
URL: https://github.com/apache/casbin-rs/issues/418#issuecomment-5206943489
@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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For additional commands, e-mail: commits-help@casbin.apache.org
Re: [I] [feature] Python bindings via PyO3 [casbin-rs]
Posted by "0xZKc0de (via GitHub)" <gi...@apache.org>.
0xZKc0de commented on issue #418:
URL: https://github.com/apache/casbin-rs/issues/418#issuecomment-5312460224
Hi @hsluoyz ,
While researching high-performance authorization options for Python and exploring Rust bindings, I came across this issue. I noticed there hasn't been recent activity on it, and I am very interested in taking it on.
My plan is to build Python bindings for `casbin-rs` using **PyO3** and **Maturin** to provide a high-performance alternative to `pycasbin`. I am currently working on a simple Proof of Concept (PoC) to benchmark the performance.
Would you prefer I build this in a standalone repository first and share the PoC here, or is there a specific plan to host it under the official `casbin` organization?
Looking forward to your thoughts!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@casbin.apache.org
For additional commands, e-mail: commits-help@casbin.apache.org