DEV Community: Ghazanfar Uruj

Find the regex that can freeze your Python service - before it ships

Ghazanfar Uruj — Wed, 10 Jun 2026 10:56:41 +0000

A regex like ^(\w+)+$ looks harmless. But feed it a long string that almost matches and it can backtrack exponentially — a couple dozen characters can take seconds, and a slightly longer one can peg a CPU core and hang the thread indefinitely. That's a ReDoS (Regular-expression Denial of Service), and a single user-facing input field is all it takes.

I wanted those patterns caught automatically, in CI, so I built redos — a small, dependency-free CLI.

How it works

redos never imports or runs your code. It parses each .py file with the standard-library ast module, collects every literal pattern passed to re / regex (re.compile, re.match, re.search, …), then parses each one with Python's own regular-expression parser and inspects the parsed structure for the two classic causes of catastrophic backtracking:

Nested quantifiers — a repeated group that itself repeats, like (a+)+, (a*)*, or ([a-z]+)*.
Ambiguous alternation under a repeat — branches that can match the same text, like (a|a)+.

Because it analyses the pattern after Python's own optimiser runs, it doesn't flag patterns the engine already makes safe — (abc|abd)+ has its common prefix factored out, (\w|\d)+ collapses to a single character class. That keeps false positives low, which is the thing that actually kills adoption of a linter.

Using it

pip install redos
redos .                  # scan the current project
redos . --format json    # machine-readable output

It exits non-zero when it finds a risk, so redos . drops straight into CI or a pre-commit hook:

repos:
  - repo: https://github.com/gazzycodes/redos
    rev: v0.1.0
    hooks:
      - id: redos

Why a static tool?

An AI assistant can spot a dangerous regex if you ask it about that specific line — but redos is deterministic, runs headless in CI on every commit in milliseconds, reasons over your entire project at once, and never sends your code anywhere. It's the cheap, reliable gate, the same reason linters and type checkers keep thriving.

It's open source (MIT) and early — feedback and contributions welcome: https://github.com/gazzycodes/redos

Stop shipping a .env.example that's already out of date

Ghazanfar Uruj — Wed, 10 Jun 2026 08:47:15 +0000

You add a new feature, it reads a new environment variable, you ship it. Three weeks later a teammate clones the repo, copies .env.example, runs the app — and it crashes on a KeyError for a variable nobody documented. Or the reverse: .env.example is full of variables that no code reads anymore, and new devs waste time setting them.

I wanted that drift caught automatically, so I built envcheck — a small, dependency-free CLI.

How it works

envcheck never imports or runs your code. It parses each .py file with the standard-library ast module, collects every literal-key environment-variable access (os.getenv("X"), os.environ["X"], os.environ.get("X"), os.environ.setdefault("X", ...)), then diffs that against your example env file. Dynamic keys are ignored on purpose, so it never produces noisy false positives.

Using it

pip install envcheck-sync
envcheck .                      # auto-detects .env.example, .env.sample, ...
envcheck . --format json        # machine-readable for tooling

It exits non-zero when it finds undocumented variables, so dropping envcheck . into CI or a pre-commit hook keeps your .env.example honest. It also reports possibly-unused variables as a warning (without failing) so you can prune them.

Why a static tool in the age of AI?

An AI assistant can spot a missing env var if you ask it, but envcheck is deterministic, runs headless in CI on every commit in milliseconds, reasons over your entire project at once, and never sends your code anywhere. It's the cheap, reliable gate — the same reason linters and type checkers keep thriving.

It's open source (MIT) and early — feedback and contributions welcome: https://github.com/gazzycodes/envcheck

Catching circular imports in Python before they crash you

Ghazanfar Uruj — Tue, 09 Jun 2026 10:31:04 +0000

Circular imports are one of those Python problems that stay invisible until a specific import order triggers an ImportError or a half-initialized module in production. They also quietly tighten the coupling in your codebase.

I wanted something that catches them before runtime, so I wrote knot — a small, dependency-free CLI.

How it works

knot never imports or runs your code. It parses each file with the standard-library ast module, maps every file to its fully-qualified module name, resolves both absolute and relative imports to internal modules, then finds cycles by computing strongly connected components with an iterative Tarjan's algorithm (safe on very large graphs). For each cycle it prints a concrete path like a -> b -> a.

Using it

pip install knot-imports
knot mypackage
knot mypackage --format mermaid   # draws the import graph

It returns a non-zero exit code when cycles exist, so adding knot . to CI or a pre-commit hook keeps cycles from ever reaching main.

Why a static tool in the age of AI coding?

An AI assistant can spot a cycle if you ask it, but knot is deterministic, runs headless in CI on every commit in milliseconds, reasons over your entire import graph at once, and never sends your code anywhere. It's the cheap, reliable gate — the same reason linters and type checkers keep thriving.

It's open source (MIT), and early — feedback and contributions welcome: https://github.com/gazzycodes/knot