Open-source project
mammothb/symspellpy avatar
mammothb/symspellpy

symspellpy: a Python port of SymSpell that trades speed for zero dependencies

Python port of SymSpell: 1 million times faster spelling correction & fuzzy search through Symmetric Delete spelling correction algorithm

876 stars130 forksPythonMIT

At a glance

What is it?
symspellpy is a Python port of SymSpell 6.7.2 with no runtime dependencies, ported unit tests for accuracy and an optional editdistpy accelerator. The README also warns that the port has not been optimized for speed, which sits awkwardly next to the headline claim.
Who is it for?
Adopt symspellpy if you need spell correction or fuzzy lookup in a Python service and want it to install cleanly with nothing else, since the package declares no dependencies and supports Python 3.10 through 3.14. Do not adopt it expecting the raw speed of the original SymSpell, because the README says the port has not been optimized for speed, and if you need the upstream algorithm's newest behaviour, note that the port targets SymSpell 6.7.2.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A port with no dependencies and the original test suite

symspellpy is a Python port of SymSpell, the C# implementation by wolfgarbe, and the README states that it provides much higher speed and lower memory consumption while tracking upstream version 6.7.2. The port is MIT licensed and is published on PyPI as symspellpy.

The dependency situation is the first thing worth noting, and it is unusual. The pyproject.toml declares the project with an empty dependency list, so pip install symspellpy pulls in nothing but the package itself. The project metadata requires Python 3.10 or newer, and the classifiers cover Python 3.10 through 3.14, so the package is tested against the current interpreter range rather than pinning itself to an old one.

Accuracy is handled by inheritance rather than by assertion. The README states that unit tests from the original project are implemented to ensure the accuracy of the port, which is a stronger claim than a set of hand-written tests would be, because the same test cases exercise both implementations and any divergence shows up as a failing case.

The audience is developers who want the SymSpell approach, the symmetric delete spelling correction algorithm, in a Python codebase without a .NET or Java runtime in the picture. The repository topics list the range: approximate string matching, edit distance, Levenshtein and Damerau-Levenshtein distance, fuzzy search, fuzzy matching, spelling correction, spell checking, word segmentation and Chinese text segmentation.

editdistpy is an optional extra, not a requirement

The interesting change the README highlights is the fast distance comparer implemented with editdistpy, which it credits with approximately a 2x speed up for usage under default settings. The benchmarks are published in the repository at tests/benchmarks.ipynb, so the number comes with its method attached rather than being a claim in isolation.

The dependency is optional, and the way it is declared makes that clear. The pyproject.toml defines an extra named editdistpy that requires editdistpy at version 0.1.3 or newer, and the base install keeps the empty dependency list:

toml
editdistpy = [
    "editdistpy>=0.1.3",
]

So the shape of the package is a pure Python implementation that works on its own, with a compiled or otherwise accelerated distance comparer available if you want it. That matters for deployment, because a service that installs the extra needs a build toolchain or a matching wheel for its platform, while the base install does not.

The development group shows the same optional dependency in the test environment, alongside the test tooling, which tells you the accelerated path is what the project measures itself with.

The practical question for an adopter is whether the speed difference matters for your dictionary size and query rate. A 2x improvement on a lookup that is already fast may not justify an extra dependency, while the same factor on a hot path in a search service probably will. The notebook is the place to read the conditions the figure was measured under.

The port is accurate by construction and slow by design choice

The README contains an internal tension that is worth reading closely.

The project description calls the library a Python port of SymSpell offering spelling correction and fuzzy search through the symmetric delete spelling correction algorithm, and mentions a speed claim of a million times faster in the repository description. The README body, however, adds a short sentence: please note that the port has not been optimized for speed.

Both statements can be true, and the distinction is between the algorithm and its implementation. The symmetric delete approach is what makes lookup fast, because it precomputes deletion variants instead of comparing every candidate word. The port inherits that algorithmic advantage, and the unit tests ported from the original give confidence that it behaves the same. What the port has not done is the performance work on top of the algorithm, which is what the sentence refers to.

So the honest reading is: expect SymSpell-class behaviour and accuracy, expect the Python overhead that any Python implementation carries, and do not read the project description as a promise about this port's own throughput. If throughput is the deciding factor, the benchmark notebook is the honest starting point because it measures this implementation, not the original.

There is a second versioning wrinkle to keep in mind. The project version is 6.10.0, while the README says the port tracks SymSpell 6.7.2, so the two version numbers are not comparable. What the number means is that the port targets a specific upstream release, and behaviour added upstream after 6.7.2 is not in this package.

Word segmentation and Chinese text are advertised by topic, not by example

The repository topics include word-segmentation, chinese-word-segmentation and chinese-text-segmentation, alongside the spelling topics. That tells you the package covers the word splitting half of SymSpell, not only the correction half, and that the segmentation side is aimed at Chinese text where words are not separated by spaces.

The README, however, says almost nothing about it. There is no code example, no explanation of how the segmentation dictionary is loaded or what the return type looks like. Instead, the README points to the examples in the documentation at symspellpy.readthedocs.io, and the documentation site carries a documentation status badge for the latest published version, so the readthedocs project is the actual API reference for this package.

The repository layout is consistent with a small, focused package. The code is in a symspellpy/ directory, the tests in tests/, the documentation sources in docs/, and the project is configured for readthedocs through a .readthedocs.yaml file. INSTALL.rst at the root holds the installation instructions, and CHANGELOG.md holds the release history, both of which are linked from the project metadata.

The directory listing is short because there is one distribution. This is a single-purpose library rather than a toolkit, so the question for an adopter is narrow: does the SymSpell approach fit your correction and lookup problem, and are you willing to read the documentation site to learn the API rather than a README example.

The development toolchain is pinned exactly, down to the test runner

The pyproject.toml is unusually specific about the tooling, and that tells you how the project is maintained.

Tests run on pytest at version 9.0.3 with pytest-cov 6.0.0 and pytest-xdist 3.8.0, and the pytest configuration sets the options that make the suite parallel:

toml
addopts = "-n auto --dist loadscope"

The -n auto setting runs as many workers as the machine has cores, and the loadscope distribution mode groups tests by class so that tests sharing fixtures do not land on different workers. That is the right choice for a suite that ports the original project's test cases, where many cases build the same dictionaries.

The type and lint side is configured too. basedpyright is set to target Python 3.10, and its configuration for the tests directory loosens a specific set of rules, including reportAny and the private usage checks, which is the usual accommodation for a test suite that pokes at internals. Ruff is configured with a line length of 88 and an indent width of 4, and a .coveragerc file at the root governs coverage measurement. There is also a uv.lock file, so the environment is pinned with uv, and the .github/ directory holds the workflow that the tests badge points at.

The build backend is setuptools with wheel, requiring setuptools 61.0.0 or newer. The project is marked with the development status classifier for beta, which is an honest signal about the maturity the author is claiming.

Where to get it, and what to check before you pin a version

The README deliberately keeps installation short. It says to see the INSTALL.rst file or the install page in the documentation for installation instructions, and the examples section of the documentation for sample usage. So the two places to look are INSTALL.rst in the repository root and the installation page on readthedocs.

On versions, the release history is the changelog. The three most recent releases listed are v6.9.0 on 2025-03-09, then v6.10.0-rc1 and v6.10.0 both on 2026-07-11, the release candidate and the final version landing minutes apart on the same day. The metadata in pyproject.toml matches the final release at version 6.10.0.

The gap between those two release dates is worth noting if you are deciding how much risk to take. The last push was on 2026-08-21, so work has continued since 6.10.0, but the project publishes releases on its own schedule rather than on a fixed cadence, and the jump from 6.9.0 to 6.10.0 after more than a year suggests changes beyond a patch. The CHANGELOG.md file is where the detail sits.

There is no homepage listed for the repository, and the documentation site on readthedocs is the project's public face. If you are evaluating it as a dependency, the two checks that matter are the accuracy story, which rests on the ported unit tests, and the performance story, which rests on the benchmark notebook. Both are in the repository, and neither requires you to take the description on trust.

Editorial conclusion

Adopt symspellpy if you need spell correction or fuzzy lookup in a Python service and want it to install cleanly with nothing else, since the package declares no dependencies and supports Python 3.10 through 3.14. Do not adopt it expecting the raw speed of the original SymSpell, because the README says the port has not been optimized for speed, and if you need the upstream algorithm's newest behaviour, note that the port targets SymSpell 6.7.2. Before you depend on it, read INSTALL.rst for the install step the README defers to, and measure the editdistpy extra against your own dictionary, since the roughly 2x figure the README quotes comes from the project's own benchmarks notebook rather than from your workload.

Frequently asked questions

What is symspellpy and how does it relate to SymSpell?

symspellpy is a Python port of SymSpell 6.7.2, using the symmetric delete spelling correction algorithm, and it is MIT licensed. The README states that unit tests from the original project were implemented to ensure the accuracy of the port, and that the port itself has not been optimized for speed.

Does symspellpy have any runtime dependencies?

No. The pyproject.toml declares an empty dependency list, and the package requires Python 3.10 or newer, with classifiers for Python 3.10 through 3.14. The fast distance comparer based on editdistpy is an optional extra, with editdistpy>=0.1.3, that the README credits with roughly a 2x speed up under default settings.

How do I install symspellpy?

The README refers you to the INSTALL.rst file in the repository or the install page in the documentation at symspellpy.readthedocs.io for installation instructions, and to the examples section of the documentation for sample usage.

Does symspellpy support word segmentation and Chinese text?

The repository topics list word-segmentation, chinese-word-segmentation and chinese-text-segmentation alongside the spelling correction topics, so segmentation is part of the scope. The README itself gives no example of it and points to the documentation site for sample usage.

Which version of symspellpy is current?

The project metadata in pyproject.toml declares version 6.10.0, which was published on 2026-07-11 together with the release candidate v6.10.0-rc1. The previous listed release is v6.9.0 from 2025-03-09, and the last push to the repository was on 2026-08-21.

Official sources

  1. Issues
  2. License: MIT
  3. mammothb/symspellpy on GitHub
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/mammothb-symspellpy.svg)](https://hysenlabs.com/projects/mammothb-symspellpy)

Was this useful?