Open jameshilliard opened 5 years ago
Will take a look, thanks!
So, the use-case is to use brotli library if it is already installed?
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.
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.
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.