Go-to-market and marketing is what I do for a living. Reading other people's code is the habit next to it, and at some point I wrote my own screener for it.

driftkit

github.com/karpovantonme/driftkit

Every check in it has the same shape: two statements about the same thing, in two places, and nobody compares them. A docstring against the signature under it. A \param name against the declaration it documents. A CI matrix against the versions a package claims to support. A vendored copy against the upstream commit that fixed it. A link in the docs against the server that stopped answering.

Linters don't find these, because a linter reads the code. Here you have to read the code and the thing next to it. Python 3.9+, standard library only, MIT.

What came out of it

57 changes landed across 44 projects so far, among them Apple's Swift Foundation, Bazel, curl, Microsoft GraphRAG, scikit-learn, OpenCV, libgit2, rclone, etcd, OpenTelemetry Collector, Thanos, AFL++, PCRE2, Traefik, JetBrains, five Boost libraries, NetworkX, statsmodels, MNE-Python, QuTiP, AstroPy and ibis.

Four of those do not show as merged pull requests, because the project landed the code another way. Bazel runs contributions through Google's internal pipeline. Go merges through Gerrit: golang.org/cl/811340, reviewed by Keith Randall and Dmitri Shuralyov. In curl the maintainer applied the patch by hand (05ddf551) and closed the pull request afterwards. In GraphRAG a maintainer carried both fixes into his own branch (00adeaf7) and closed mine a second after his merged.

The tool proposes and I decide. Every finding is read by hand before it becomes a pull request, and the ones that turn out to be wrong go into FALSE-POSITIVES.md instead of quietly disappearing.

Things I've shipped

karpovanton.com