SymPy: a computer algebra system in pure Python

What SymPy solves, and who reaches for it

Floating point answers are approximations. Sometimes that is fine. Sometimes it is not: you need the derivative as an expression, the integral in closed form, an exact rational coefficient, or a matrix whose determinant you can inspect rather than evaluate. SymPy is a computer algebra system written in pure Python, so those operations happen inside an ordinary Python process, with no compiled extension to install and no separate language to learn.

The audience is correspondingly specific. Researchers and engineers who already write Python and want symbolic steps in the same script. Instructors who want students to see an expression transform rather than a number appear. Library authors who need exact algebra inside a larger pipeline. The README frames the project around a community as much as a library, pointing to a mailing list, a Gitter channel and a Stack Overflow tag, which is a fair signal of what the project expects from users.

Expressions stay symbolic: how the core actually behaves

The central object is the expression tree. You build it from Symbol instances and ordinary Python operators, and SymPy keeps it unevaluated in the sense that matters: 1/cos(x) does not become a float. The README's own example makes the point, printing a truncated series with an order term still attached:

>>> from sympy import Symbol, cos
>>> x = Symbol('x')
>>> e = 1/cos(x)
>>> print(e.series(x, 0, 10))
1 + x**2/2 + 5*x**4/24 + 61*x**6/720 + 277*x**8/8064 + O(x**10)

Everything else in the library is built on that tree: solve, integrate, simplify, dsolve and the matrix types all take expressions in and return expressions out. The conversion to numbers is a separate, explicit step. lambdify turns an expression into a callable that operates on arrays, which is the usual bridge to NumPy when you finally want values. Keeping that boundary explicit is the design decision that makes the library useful, and it is also the source of most of its cost.

Installing SymPy with pip and running a first symbolic solve

The README gives two package-manager routes and one source route. The Python requirement is enforced in setup.py, which exits with a message if the interpreter is older than 3.10, so the install command is only half the story: check the interpreter first.

$ pip install sympy

The README also documents the Anaconda route, which is the method it recommends:

$ conda install -c anaconda sympy

To install from the repository instead, clone it and install from the checkout. The README notes that running pip install . from inside the cloned sympy directory is enough.

$ git clone https://github.com/sympy/sympy.git
$ cd sympy
$ pip install .

With the package installed, the interactive entry point is isympy, a console wrapper that loads the SymPy namespace and executes some common commands for you. The README lists it as a console script, so it is available on the path after installation.

$ isympy

For a first real use, the README's own short usage is the place to start: define a symbol and build an expression from it. The subs method is the one to remember, because it is how you move from a symbolic answer to a concrete one without leaving the expression behind.

>>> from sympy import Symbol, cos
>>> x = Symbol('x')
>>> e = 1/cos(x)
>>> print(e.series(x, 0, 10))
1 + x**2/2 + 5*x**4/24 + 61*x**6/720 + 277*x**8/8064 + O(x**10)

What you should see is a truncated series with the order term O(x**10) still attached, rather than a decimal approximation. If the interpreter is older than 3.10, the install will not proceed.

Where SymPy gets slow, and when it is the wrong tool

Symbolic work is not free. Expression trees grow, and operations such as simplify search across rewrite rules, so a single call can take far longer than the arithmetic it replaces. The repository acknowledges this in its own test configuration: pyproject.toml sets pytest addopts to exclude tests marked slow and tooslow by default, and registers both markers. The project's own suite therefore separates the expensive paths from the default run, which tells you the maintainers consider some operations heavy enough to keep out of the ordinary loop.

That is the practical boundary. If your problem is a large dense numerical computation, SymPy is the wrong layer: an expression tree per element is a poor representation for that workload, and the conversion back to numbers through lambdify is an extra step you would not need if you had started numerically. If your problem is a symbolic manipulation that happens to be huge, expect to tune it, and expect some operations to be slow enough that the test suite will not run them unless asked.

There is a second, smaller failure mode worth naming. The README documents no rollback procedure and no version pinning guidance, so a bad upgrade is handled with the ordinary Python packaging tools rather than anything SymPy provides. If your workflow depends on a specific simplification behaving a specific way, that is on you to pin.

SymPy against NumPy, and against a compiled algebra system

The comparison people actually make is with NumPy, and the difference is the representation, not the domain. NumPy stores arrays of numbers and computes on them; SymPy stores expressions and rewrites them. A NumPy operation on a million elements is the intended use. The same operation through SymPy would build a million-node tree and then need lambdify to get back to numbers. They are not competitors so much as consecutive stages, and the README's own example, a series expansion, is something NumPy has no representation for at all.

The other comparison is with a compiled computer algebra system. Here the trade is portability against speed. SymPy is pure Python, so it runs wherever Python runs, including environments where you cannot install a native binary, and it is importable from the same process as the rest of your code. A compiled system will generally handle heavy symbolic workloads with less tuning. Choosing SymPy means choosing the Python process and the readable source tree over raw symbolic throughput, and for scripted derivations and teaching that trade usually goes the right way.

Maintenance, upgrades and the licence file

The repository is not archived, and the last push was on 2026-09-21. The most recent release listed is 1.14.0, dated 2025-04-27, preceded by two release candidates in April 2025. So the pattern is a long-lived project with periodic tagged releases and continuous work on master between them.

The upgrade cost is mostly the Python floor. setup.py keeps the minimum version in sync with sympy/__init__.py and refuses to install below 3.10, so a SymPy upgrade can force an interpreter upgrade in the environments around it. The project also pins its own tooling: pyproject.toml sets ruff target-version to py310 and configures a specific lint selection, which is a contributor concern rather than a user one, but it tells you the codebase is written to that floor.

On licensing, the two sources disagree in form. The repository metadata reports NOASSERTION, while the README states that the New BSD License covers all files in the sympy repository unless stated otherwise, pointing at the LICENSE file. Treat the LICENSE file as the authoritative text and read it before redistributing; nothing here is legal advice.

Editorial conclusion

Adopt SymPy when the answer has to stay exact and the surrounding code is already Python: scripted derivations, symbolic Jacobians, teaching notebooks, unit-checked transforms. Do not adopt it as a replacement for NumPy or a compiled CAS on large dense numerical problems, and do not expect the README to tell you how to pin a version or roll back a bad upgrade. Before committing, check the Python floor of 3.10 in setup.py, run one representative expression through sympy.simplify to see whether the simplification cost is acceptable, and read the LICENSE file, since the repository metadata reports NOASSERTION while the README states the New BSD License.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sympy/sympy on GitHub