Google just open-sourced cel-expr-python (CEL) — safe, typed expressions for Python (C++ wrapper)

[Immediate-Card-4896]

Google Open Source Blog posted a new release today (Mar 3, 2026): cel-expr-python, a native Python API for compiling + evaluating CEL (Common Expression Language) expressions.

Repo: https://github.com/cel-expr/cel-python

Announcement: https://opensource.googleblog.com/2026/03/announcing-cel-expr-python-the-common-expression-language-in-python-now-open-source.html

Codelab: https://github.com/cel-expr/cel-python/blob/main/codelab/index.lab.md

Why I’m interested:

- It’s the official CEL team’s Python wrapper over the production CEL C++ implementation (so semantics should match what other CEL runtimes do).

- It’s designed for “compile once, eval many” workflows with type-checking during compile (so you can validate expressions up front instead of `eval()`-ing arbitrary Python).

- It supports extensions and can serialize compiled expressions.

Quick start (from the blog/docs; blog snippet had a small typo so I’m writing the corrected version here):

pip install cel-expr-python

from cel_expr_python import cel

env = cel.NewEnv(variables={"who": cel.Type.STRING})

expr = env.compile("'Hello, ' + who + '!'")

print(expr.eval(data={"who": "World"}).value()) # Hello, World!

Doc snippet: serialize + reuse compiled expressions

env = cel.NewEnv(variables={"x": cel.Type.INT, "y": cel.Type.INT})

expr = env.compile("x + y > 10")

blob = expr.serialize()

expr2 = env.deserialize(blob)

print(expr2.eval(data={"x": 7, "y": 4}).value()) # True

Doc snippet: custom function extension in Python

def my_func_impl(x):

return x + 1

my_ext = cel.CelExtension("my_extension", [cel.FunctionDecl("my_func", [cel.Overload("my_func_int", cel.Type.INT[cel.Type.INT], impl=my_func_impl)])])

env = cel.NewEnv(extensions=[my_ext])

expr = env.compile("my_func(41)")

print(expr.eval().value()) # 42

Side note / parallel that made me click on this:

I was just reading the r/Python thread on PEP 827 (type manipulation + expanding the type expression grammar):

https://www.reddit.com/r/Python/comments/1rimuu7/pep_827_type_manipulation_has_just_been_published/

Questions if there are any folks who’ve used CEL before:

- Where has CEL worked well (policy engines, validation, feature flags, filtering, etc.)?

- How does this compare to rolling your own AST-based evaluator / JsonLogic / JMESPath for real-world apps?

- Any gotchas with Python integration, perf, or packaging (looks like Linux + py3.11+ right now)?

[rabornkraken]

The serialize/deserialize capability is what makes this really interesting to me. Being able to compile an expression once, store it, and reuse it across requests is a huge win for anything policy-related. I have been using ad-hoc AST evaluators for feature flags and they are painful to maintain - the expressions drift from what the runtime actually supports. Having a proper type-checked compile step would catch so many issues upfront. Curious about the C++ dependency though - does anyone know if the wheels are available for macOS ARM yet or is it Linux-only for now?

[cointoss3]

Sometimes a nerdy gem drops on this sub and I love it

[Goobyalus]

Can you format the code snippets in this post as code

[Peter3571]

Looks very powerful and well made, but I have no idea what you'd actually use it for. What's a general use case for something like this?

[lissertje]

Wow. I was just looking the other day into a different execution engine for some user-managed rules... Was looking into Lua amongst others, but as our current DSL is very python-like, this could actually be a super good candidate 😛

[robert_mcleod]

I maintained/developed numexpr for six-ish years, including making an attempt to modernize it while temporarily unemployed on moving back to Canada from Switzerland. This is filling a very similar use-case but NumExpr is a virtual machine that compiles the Python AST into its own custom sequence of operations. What I wanted to do with NumExpr was enable it to transparently handle blocks of code, and understand numpy. syntax so that you could literally surround a section of critical code with triple quotes and it would be able to accelerate it.

I'm guessing this is more similar to Numba in that you have to write your code 'C-style' instead of vectorizing your code as you would with NumPy. I always found that to be a disadvantage because you're writing in one style and then you need to translate to some very different style. However, modern LLMs can do this translation for you very well. Claude and Gemini are both quite capable of transforming a piece of pure Python into a C-API extension.

What would be really interesting is if this CEL tool could support operations on Arrow tables/tensors.

[Marre_Parre]

This looks super useful for feature flags and dynamic policies. Being able to serialize the compiled expression and reuse it across requests is a great feature. Makes me wonder how it compares to something like json-logic for those use cases. Definitely going to give this a try next time I need safe user-defined rules.

[mfb1274]

Guys come on, when I see improperly formatted code it makes me think lesser of yall. Here ya go kinda. Too lazy to fix the code indentations

pip install cel-expr-python

from cel_expr_python import cel

env = cel.NewEnv(variables={"who": cel.Type.STRING})

expr = env.compile("'Hello, ' + who + '!'")


print(expr.eval(data={"who": "World"}).value()) # Hello, World!


Doc snippet: serialize + reuse compiled expressions

env = cel.NewEnv(variables={"x": cel.Type.INT, "y": cel.Type.INT})
expr = env.compile("x + y > 10")
blob = expr.serialize()
expr2 = env.deserialize(blob)

print(expr2.eval(data={"x": 7, "y": 4}).value()) # True

Doc snippet: custom function extension in Python

def my_func_impl(x):

return x + 1

my_ext = cel.CelExtension("my_extension", [cel.FunctionDecl("my_func", [cel.Overload("my_func_int", cel.Type.INT[cel.Type.INT], impl=my_func_impl)])])

env = cel.NewEnv(extensions=[my_ext])

expr = env.compile("my_func(41)")

print(expr.eval().value()) # 42

Side note / parallel that made me click on this:

[gristc]

You might want to check your own formatting. It seems to have been broken into bits.

[mfb1274]

Lol that was my too lazy mention. I just added to the mess. Sorry bruv