Ask HN: Why dead code detection in Python is harder than most tools admit
4 points
11 hours ago
| 0 comments
| HN
I’ve been thinking about why dead code detection (and static analysis in general) feels so unreliable in Python compared to other languages. I understand that Python is generally dynamic in nature.

In theory it should be simple(again in theory): parse the AST, build a call graph, find symbols with zero references. In practice it breaks down quickly because of many things like:

1. dynamic dispatch (getattr, registries, plugin systems)

2. framework entrypoints (Flask/FastAPI routes, Django views, pytest fixtures)

3. decorators and implicit naming conventions

4. code invoked only via tests or runtime configuration

Most tools seem to pick one of two bad tradeoffs:

1. be conservative and miss lots of genuinely dead code

or

2. be aggressive and flag false positives that people stop trusting

What’s worked best for me so far is treating the code as sort of a confidence score, plus some layering in limited runtime info (e.g. what actually executed during tests) instead of relying on 100% static analysis.

Curious how others handle this in real codebases..

Do yall just accept false positives? or do yall ignore dead code detection entirely? have anyone seen approaches that actually scale? I am aware that sonarqube is very noisy.

I built a library with a vsce extension, mainly to explore these tradeoffs (link below if relevant), but I’m more interested in how others think about the problem. Also hope I'm in the right channel

Repo for context: https://github.com/duriantaco/skylos

No one has commented on this post.