# Algorithmic complexity of difflib

**URL:** <https://discuss.python.org/t/algorithmic-complexity-of-difflib/105844>\
**Category:** Ideas\
**Created:** [January 21, 2026, 2:02am UTC](https://discuss.python.org/t/algorithmic-complexity-of-difflib/105844 "2026-01-21T02:02:32Z")\
**Posts on this page:** 1\
**Showing post:** 138

<div class="post-metadata">

**Author:** ![dg-pb](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dg-pb/32/16248_2.png) [@dg-pb](https://discuss.python.org/u/dg-pb)\
**Post date:** [August 8, 2026, 6:24pm UTC](https://discuss.python.org/t/algorithmic-complexity-of-difflib/105844/138 "2026-08-08T18:24:43Z")

</div>

> [@pf\_moore](#):
>
> do you intend to publish the resulting code as a library on PyPI and/or submit it as a PR to the stdlib?

Intent was always to improve `difflib`. There is a standing [PR](https://github.com/python/cpython/pull/145210) which adds composability so that new matchers can be used with all utilities there. So that is the 1st step. After that is done, I had 2 trajectories:

1. PR1 for improved utilities and a bit of preparation, then PR2 with SAM based matcher above.
2. Improving existing `SequenceMatcher` so that the issues with default matcher are reduced to a minimum. See [Improvement on current `difflib.SequenceMatcher` algorithm](https://discuss.python.org/t/improvement-on-current-difflib-sequencematcher-algorithm/106221)

Will see how this goes. From my experience things are moving rather slowly when it comes to algorithms.

---

_[View the full topic](https://discuss.python.org/t/algorithmic-complexity-of-difflib/105844)._