Patsy keeps R-style model formulas working in Python

R formulas without leaving Python

Patsy exists to move one specific idea from R into Python: the formula. In R you describe a model as a string such as a response on the left of a tilde and predictor terms on the right, and the tooling derives the design matrix from that specification. Patsy brings that convenience to Python for statistical models, and the project is explicit about the focus: models that have a linear component, with linear models named first.

The payoff is that the model specification lives in one readable place instead of being spread across a sequence of numpy calls. The same description can be reused, saved, and passed around, and the library handles turning it into the numeric array that a modelling function actually consumes. That is a genuine convenience for the class of work the library targets, and it explains why Patsy ended up underneath so much of the Python statistics stack rather than being used directly.

The audience is therefore narrower than the general Python data community. It is for people writing models, not people doing general numeric work, and for people who already think in terms of a formula language. A team that never needs a design matrix has no reason to reach for it.

There is also a context that matters for any adoption decision, and the README states it plainly: Patsy is no longer under active development.

What actually happens when a formula is parsed

The visible mechanism is a formula string that is parsed into terms, each of which is then evaluated against the data to produce a column of the design matrix. The formula language itself is where the interesting behaviour lives, because the same syntax has to cover categorical terms, interactions, and functions.

The clearest hint about the scope is the dependency list. The package requires numpy, and the setup file declares the floor as numpy >= 1.4, with a comment in the source noting that a newer numpy might be needed but that at least 1.4 is required for triu_indices. That single function name tells you the implementation reaches into numpy routines that go back a long way, and that the library is bound to the numeric array layer rather than to a dataframe abstraction.

The second required dependency is packaging, which is what makes version parsing portable across Python environments. Optional extras exist as well: the test extra lists pytest, pytest-cov and scipy, and the README notes that scipy is needed for spline related functions such as bs. So the library has a small core dependency set and a clearly separated set of features that pull in more.

Everything sits under a single top level package directory, patsy/, with the version read from patsy/version.py at build time by executing that file from setup.py. The version is therefore owned by the source tree rather than hardcoded in the packaging script.

Installing with pip and the Python floor it declares

Installation is a single command, given in the README:

pip install patsy

There is a second route for anyone who prefers the older style:

python setup.py install

The minimum Python version is 3.6, and the packaging metadata states the same constraint through python_requires, set to >=3.6. The classifier list in setup.py runs from Python 3.6 through 3.14, which is a detail worth noticing: it tells you the packaging metadata has been kept current against new Python releases even though the library itself is frozen.

The setup file also declares the package metadata in a readable way. The description is a single sentence, and the author fields still point to Nathaniel J. Smith, the original author, even though maintenance later moved to different hands. The project publishes a PyPI page for the package, hosts its documentation on readthedocs, and carries a Zenodo DOI badge at 10.5281/zenodo.592075 for citing a specific release of the software.

For most users the practical installation question is settled by pip. The interesting question is which version you land on, because Patsy is still installed as a dependency of other packages whether or not you want it.

A dependency that arrives without being asked for

The dependency story of Patsy is more interesting than the two-line install command suggests, because the library is a dependency of other projects rather than something people usually choose on its own.

Patsy is rarely chosen directly by a user. It is depended on by other statistical software packages, which is why the README talks about the point at which major software packages will have successfully transitioned away from it. That means Patsy is frequently installed into environments by a statistical package manager pulling in a pinned or unpinned version, and the version present may not be the one a team would choose. The consequence is that Patsy tends to be encountered as an inherited constraint rather than a chosen dependency.

That changes how you should evaluate it. You do not normally get to pick the version, and the compatibility surface you care about is the one your modelling library exercises: the formula syntax it parses, the terms it produces, and the shape of the matrices it returns. A newer Patsy does not add features, it merely keeps working with current releases of the Python ecosystem.

The project frames its remaining commitment in exactly those terms. The README says the maintainers will attempt to keep Patsy working in its current state with current releases in the Python ecosystem, until the major software packages that depend on it have successfully transitioned. That is a maintenance promise about compatibility, not a development roadmap.

The maintenance notice and the successor project

The most important paragraph in the README is the notice at the top. It says Patsy is no longer under active development, that as of August 2021 Matthew Wardrop and Tomás Capretto took on responsibility from Nathaniel Smith for keeping the lights on, and that no new feature development is planned.

The README then names the successor. Patsy is described as having a spiritual successor in Formulaic, with a link to a migration guide on the Formulaic documentation site. The distinction between spiritual successor and drop-in replacement is the part to take seriously. Formulaic is where new work is happening, and the migration guide is the intended path for moving code across. Anyone reading this project should treat that link as the primary next step rather than an aside.

The release record is consistent with the notice. Version 1.0.1 was published on 2024-11-12, 1.0.2 on 2025-10-20, and 1.0.3 on 2026-08-29. The last push to the repository was on 2026-10-19. The repository is not archived and work is landing on it, but the tags show a maintenance line: patch level releases in the 1.0 series with no new minor version and no 2.0.

So the accurate description of Patsy's status is that it is being kept alive on purpose, with a named successor, and that is a healthy arrangement for a library this widely depended upon. It is not a project where new capabilities are arriving.

What you give up by not migrating

The alternative to Patsy is Formulaic, and the difference in approach is visible in the relationship the project itself describes.

Patsy is a frozen implementation of a formula language. It parses, evaluates, and builds design matrices, and it does not extend beyond that. Formulaic is where the same idea is being developed, so any behaviour you would want in a formula engine, including features that Patsy will never receive, has to be looked for there. The migration guide is what converts an existing Patsy codebase into a Formulaic one, and the README's framing is that users should move when possible.

That advice is sound for new code. It is weaker for code that depends on Patsy indirectly. If your modelling library imports Patsy and passes formula strings through it, swapping the library out means the modelling library has to move first, and the README notes that the transition is expected to be gradual because major software packages still need to move across.

The second alternative worth naming is the one that predates both: writing the design matrix yourself with numpy. The difference is explicitness. A formula keeps the model description next to the data and in a form that can be inspected, logged, and reused. Hand-built arrays are faster to produce for a fixed, simple model and give you exact control over column ordering and dtype, at the cost of losing the readable specification.

The same applies to the optional scipy features. Spline terms such as bs need scipy, so a team that only uses plain categorical and numeric terms can stay on numpy alone.

Licensing, packaging files, and the cost of staying on the old library

Patsy is released under a 2-clause BSD licence, and the README points to LICENSE.txt for the full text. The packaging metadata repeats the same identification. The 2-clause form is one of the most permissive licences in use, so incorporating Patsy into a product or an internal library carries minimal obligations, though reading the licence file yourself is the sensible step before you rely on that in a commercial context.

The repository shows the tooling of a project that still cares about its own hygiene. There is a tox.ini for running tests across environments, a .pre-commit-config.yaml for hook based checks, a .coveragerc with the coverage service badge pointing at the master branch, a MANIFEST.in controlling what ships in the source distribution, a release-checklist.txt that spells out the steps for cutting a release, and a CODE_OF_CONDUCT.md. A TODO file sits at the top level next to a doc/ directory for the documentation and a tools/ directory for helper scripts.

The upgrade cost of staying on Patsy is therefore close to zero in engineering terms. New patch releases arrive, your existing pin keeps working, and the library keeps the same API. The real cost is opportunity: the formula features and fixes you would eventually want are landing in Formulaic, and a code base that waits too long accumulates the migration work rather than avoiding it.

Editorial conclusion

Patsy suits teams with an existing R-flavoured modelling workflow in Python, especially where the modelling packages you already use depend on it for formula handling, and it suits anyone who needs a formula string to produce a design matrix without hand building numpy arrays. It does not suit a new project that wants an actively developed formula engine, because the README states that no new feature development is planned and that the successor is Formulaic. Before building new work on it, check the version of patsy your dependencies actually pull in, confirm your numpy satisfies the declared floor of numpy >= 1.4, and if you are starting something fresh, read the Formulaic migration guide the project links instead of planning around patsy.

Frequently asked questions

Official sources

1. Issues
2. pydata/patsy on GitHub
3. README
4. Releases