ta-lib-python: Cython bindings for TA-Lib, now with the C library built in

Cython and NumPy in place of the SWIG bindings

TA-Lib is a C library for technical analysis of financial market data. Its homepage lists more than 150 indicators such as ADX, MACD, RSI, Stochastic and Bollinger Bands, plus candlestick pattern recognition, with APIs for C/C++, Java, Perl, Python and .NET. The Python bindings that ship with TA-Lib itself are built on SWIG, and this project exists because those bindings are, in the maintainers' words, difficult to install and not as efficient as they could be.

ta-lib-python binds to the same C code with Cython and NumPy instead, and the project claims results 2 to 4 times faster than the SWIG interface. Inputs and outputs are NumPy arrays, and the wrapper also supports Polars and Pandas. The package installs as a single talib module, ships type stubs (_ta_lib.pyi, abstract.pyi, stream.pyi) and a py.typed marker, and has one runtime dependency: numpy. It is BSD-2-Clause licensed, written by John Benediktsson, and classified as Production/Stable on PyPI.

Each wrapper version line is tied to one TA-Lib C and NumPy pair

When the upstream TA-Lib C library released 0.6.1, it renamed its linker flag from -lta_lib to -lta-lib. The maintainers tried to autodetect both names, ran into problems, and moved to separate feature branches instead. The current mapping is: ta-lib-python 0.4.x for TA-Lib 0.4.x with NumPy 1, 0.5.x for TA-Lib 0.4.x with NumPy 2, 0.6.x for TA-Lib 0.6.x, 0.7.x for TA-Lib 0.7.x, and 0.8.x for TA-Lib 0.8.x, all three with NumPy 2. The prose above the list still calls these three branches although five are listed.

The consequence for anyone linking against a system copy of TA-Lib C is that the Python version you pip install is not free to float. An environment pinned to NumPy 1 must stay on the 0.4.x line, and a machine with TA-Lib C 0.4 installed from a distribution package pairs with 0.4.x or 0.5.x, not with the newest release. Pin the wrapper version explicitly in requirements files rather than taking whatever pip resolves.

Binary wheels carry a statically linked TA-Lib C

The simplest install is from PyPI:

python -m pip install TA-Lib

Since version 0.6.5 the project builds binary wheels with GitHub Actions that include the TA-Lib C library, and since 0.8.3 that library is statically linked into the extension. A wheel install needs no compiler and no separate TA-Lib C installation. Wheels are built for Linux on x86_64 and arm64, macOS on x86_64 and arm64, and Windows on x86_64, x86 and arm64, for Python 3.9, 3.10, 3.11, 3.12, 3.13 and 3.14. The pyproject.toml requires Python 3.9 or newer, and the cibuildwheel configuration includes an override for free-threaded cp314t and cp315t builds that tests them with pytest and pandas only, without polars.

Conda Forge also carries a package:

conda install -c conda-forge ta-lib

The project phrases that route as something that appears possible rather than something it maintains. If no wheel matches your operating system, architecture or Python version, pip falls back to a source build, and that path has its own requirements.

Source builds download and checksum TA-Lib C 0.8.3 at build time

Starting with 0.8.3, a source build does not look for TA-Lib C on your system by default. setup.py pins TALIB_C_VERSION to 0.8.3 along with a SHA256 digest, downloads ta-lib-0.8.3-src.tar.gz from the TA-Lib GitHub releases, verifies the digest, and builds it with CMake in Release mode into a temporary prefix before statically linking it into the Python extension. If the digest does not match, the build stops with RuntimeError: TA-Lib C source checksum mismatch.

This means a source build needs network access, a C compiler and CMake. CMake arrives automatically under pip's default build isolation, since it is listed in the build-system requirements alongside setuptools, Cython and numpy. On Windows, the Microsoft C++ Build Tools are required. The download step is a real obstacle on air-gapped build servers or behind proxies that block GitHub. setup.py does read a TA_LIB_SOURCE environment variable that can point to a local source directory or tarball containing a single TA-Lib C tree with a CMakeLists.txt, which gives offline builders a way around the fetch. Otherwise it raises an error naming TA_LIB_SOURCE.

TA_INCLUDE_PATH and TA_LIBRARY_PATH switch off the bundled build

To compile against a TA-Lib C library you installed yourself, set TA_INCLUDE_PATH or TA_LIBRARY_PATH before building. Setting either one disables the bundled C build and its download. If only one is set, the other falls back to the standard search paths. Both accept several directories separated by os.pathsep, which is a colon on Unix and a semicolon on Windows. They only affect source builds; a prebuilt wheel ignores them, so you must force a source build to use them:

export TA_LIBRARY_PATH=$PREFIX/lib
export TA_INCLUDE_PATH=$PREFIX/include
python -m pip install --no-binary=TA-Lib TA-Lib

On macOS with Homebrew, the paths come from the formula prefix:

export TA_INCLUDE_PATH="$(brew --prefix ta-lib)/include"
export TA_LIBRARY_PATH="$(brew --prefix ta-lib)/lib"

The trap here is the version table. Once these variables are set, you are no longer getting the pinned 0.8.3 C code, and the wrapper line you install has to match whatever TA-Lib C version sits under that prefix.

Installing TA-Lib C by hand has platform-specific failure modes

On macOS, Homebrew installs the C library:

brew install ta-lib

On Apple Silicon with mixed-architecture Homebrew setups, force the native build, and if several attempts have failed, reinstall without the pip cache using an arm64 Python:

arch -arm64 brew install ta-lib

your-arm64-python -m pip install --no-cache-dir ta-lib

On 64-bit Windows the C library comes as ta-lib-0.8.3-windows-x86_64.msi, which can run interactively or through msiexec; zip archives exist for x86_64 and 32-bit x86. On Linux, download ta-lib-0.8.3-src.tar.gz and build it:

tar -xzf ta-lib-0.8.3-src.tar.gz
cd ta-lib-0.8.3/
./configure --prefix=/usr
make
sudo make install

Two failures are called out. A parallel make -jX fails on the first run; rerunning make -jX and then make install gets past it. And a directory path containing spaces breaks the install with No such file or directory errors, so unpack the source somewhere with a plain path.

Two build errors that mean the C library was not found

When a source build cannot see TA-Lib C, the failure shows up at compile or link time rather than at import. One form is a missing header during compilation of the generated C file:

talib/_ta_lib.c:601:10: fatal error: ta-lib/ta_defs.h: No such file or directory
  601 | #include "ta-lib/ta_defs.h"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

The other, on Windows, is a linker that cannot resolve TA-Lib symbols such as TA_SetUnstablePeriod and TA_Shutdown, reported as error LNK2001 against common.obj. The first says the include directory is wrong or empty; the second says the compiler found headers but the linker found no matching library. Both are the situation TA_INCLUDE_PATH and TA_LIBRARY_PATH exist to fix, and both point back to the version table: headers from one TA-Lib C release paired with a library built under a different name or version produce exactly this kind of mismatch. With the 0.8.3 bundled build left on, neither variable needs to be set at all.

The repository Dockerfile still builds TA-Lib C 0.4.0 on Python 3.7

The Dockerfile at the root of the repository has fallen behind the package. Its PYTHON_VERSION build argument defaults to 3.7, while pyproject.toml requires Python 3.9 or newer. Its builder stage downloads ta-lib-0.4.0-src.tar.gz from SourceForge, configures it into /opt/ta-lib-core, and sets TA_LIBRARY_PATH and TA_INCLUDE_PATH to that prefix. Under the current setup.py, those variables disable the bundled 0.8.3 build, so the image would try to compile the 0.8.x wrapper against TA-Lib C 0.4.0, a pairing the branch table assigns to the 0.4.x and 0.5.x lines only.

The file is still useful as a template: it installs the package, runs a smoke test that computes talib.SMA over 100 random values, builds a wheel, optionally runs the test suite through the RUN_TESTS argument, and copies the wheel into a slim final image. Anyone containerizing ta-lib-python today should pass a supported PYTHON_VERSION and either drop the TA-Lib C 0.4.0 stage so the bundled build runs, or check out a matching older branch. The latest release is v0.8.3 from October 28, 2026, and pyproject.toml already reads 0.8.4.

Editorial conclusion

Use ta-lib-python if you need TA-Lib's indicators and candlestick pattern functions from NumPy, Pandas or Polars code and your platform is covered by the prebuilt wheels for Python 3.9 to 3.14. Be more careful if you build from source on an offline machine, link against a system TA-Lib C install, or rely on the repository Dockerfile. Before installing, check that the ta-lib-python version line matches the TA-Lib C and NumPy versions you plan to use.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. README
4. Releases
5. TA-Lib/ta-lib-python on GitHub