Python cffi bindings #290

New Issue

claunia · 2026-01-29T20:41:27Z

claunia commented

2026-01-29 20:41:27 +00:00

Originally created by @jameshilliard on GitHub (Aug 31, 2019).

It would be handy to have pure c cffi python bindings that don't require c++ for use on both embedded systems that don't build a c++ toolchain and for pypy which performs best using cffi instead of cpython extensions. The unmaintained brotlipy fork has cffi bindings that could be adapted for this project as a build option.

Originally created by @jameshilliard on GitHub (Aug 31, 2019). It would be handy to have pure c cffi python bindings that don't require c++ for use on both embedded systems that don't build a c++ toolchain and for pypy which performs best using cffi instead of cpython extensions. The unmaintained [brotlipy](https://github.com/python-hyper/brotlipy) fork has cffi bindings that could be adapted for this project as a build option.

claunia added the help wanted label 2026-01-29 20:41:27 +00:00

claunia commented

2026-01-29 20:41:28 +00:00

@eustas commented on GitHub (Sep 9, 2019):

Will take a look, thanks!

@eustas commented on GitHub (Sep 9, 2019): Will take a look, thanks!

claunia commented

2026-01-29 20:41:28 +00:00

@eustas commented on GitHub (Sep 9, 2019):

So, the use-case is to use brotli library if it is already installed?

@eustas commented on GitHub (Sep 9, 2019): So, the use-case is to use brotli library if it is already installed?

claunia commented

2026-01-29 20:41:28 +00:00

@jameshilliard commented on GitHub (Sep 9, 2019):

Not really, it's mostly so that a c++ toolchain isn't required and so that there's an optimized version for use with pypy.

See here:

CPython C extension modules: Any C extension module recompiled with PyPy takes a very large hit in performance. PyPy supports C extension modules solely to provide basic functionality. If the extension module is for speedup purposes only, then it makes no sense to use it with PyPy at the moment. Instead, remove it and use a native Python implementation, which also allows opportunities for JIT optimization. If the extension module is both performance-critical and an interface to some C library, then it might be worthwhile to consider rewriting it as a pure Python version that uses CFFI for the interface.

@jameshilliard commented on GitHub (Sep 9, 2019): Not really, it's mostly so that a c++ toolchain isn't required and so that there's an optimized version for use with pypy. See [here](https://pypy.org/performance.html): > CPython C extension modules: Any C extension module recompiled with PyPy takes a very large hit in performance. PyPy supports C extension modules solely to provide basic functionality. If the extension module is for speedup purposes only, then it makes no sense to use it with PyPy at the moment. Instead, remove it and use a native Python implementation, which also allows opportunities for JIT optimization. If the extension module is both performance-critical and an interface to some C library, then it might be worthwhile to consider rewriting it as a pure Python version that uses CFFI for the interface.

claunia commented

2026-01-29 20:41:28 +00:00

@sethmlarson commented on GitHub (Nov 17, 2020):

I'd like to mention that brotlipy is maintained and will be migrating to the name brotlicffi to avoid name collisions in the brotli Python namespace. This issue can likely be closed.

@sethmlarson commented on GitHub (Nov 17, 2020): I'd like to mention that `brotlipy` is maintained and will be migrating to the name `brotlicffi` to avoid name collisions in the `brotli` Python namespace. This issue can likely be closed.

claunia referenced this issue

2026-01-29 20:51:28 +00:00

[PR #290] [MERGED] s/Error of success/Error or success/ #888

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/brotli#290