A principled static effect analyzer for Python
Sidewinder is an experimental static analysis framework for Python that focuses on effect tracking (heap mutation, I/O, external interactions) using symbolic execution with delayed resolution.
The core idea is simple but deliberate:
Do not solve effects when they occur — record them symbolically and resolve them only when enough context is available (e.g., at call sites).
This makes Sidewinder more robust to Python’s dynamic features than traditional static analyzers, while still providing strong convergence guarantees.
Python breaks most static analyzers because:
- aliasing is pervasive and implicit
- control flow is dynamic
- effects are hidden behind magic methods
- loops and recursion explode state space
- libraries redefine semantics (e.g.,
append,__getattr__, IO abstractions)
Sidewinder does not try to fully evaluate Python programs.
Instead, it answers a narrower but critical question:
What effects may occur, on what objects, and through which indirections?
Sidewinder tracks effects, not concrete values.
Examples:
- heap mutations
- file reads / writes
- API calls
- thread submission
- service registration / invocation
Values are represented symbolically only insofar as they influence effects.
Sidewinder does not resolve:
- aliasing
- dynamic dispatch
- magic method semantics
- concrete paths or filenames
at the point where they occur.
Instead, it records symbolic effect descriptions that are later resolved when:
- arguments are concrete
- call context is known
- abstractions collapse
This avoids premature over-approximation.
Every function is transformed conceptually as:
f(concrete_args) -> concrete_return
into:
f(sidewinder_args) -> (sidewinder_return, propagated_effects)
Where:
sidewinder_argsencode aliasing and indirectionsidewinder_returnencodes outgoing effects- effects are first-class objects
Aliasing is not inferred implicitly.
Sidewinder tracks aliasing via symbolic references through:
- integer indexing (
x[i]) - string keys (
x["k"]) - attributes (
x.attr)
All Python indirections reduce to one of these forms.
Sidewinder does not:
- solve path conditions
- infer branch feasibility
- reason about numeric ranges unless trivial
Path sensitivity is preserved only when it does not cause state explosion.
This is a deliberate tradeoff to ensure convergence.
Sidewinder uses:
- finite-height effect lattices
- idempotent effect joins
- aggressive collapsing (widening-like behavior)
Loops and recursion are analyzed via fixpoint iteration, but without assuming termination of the program itself.
If an effect does not converge under abstraction, Sidewinder intentionally degrades precision rather than diverging.
- Heap aliasing and mutation
- Object graphs and shared references
- Dynamic dispatch via magic methods
- File I/O (via symbolic path templates)
- Service registration and invocation patterns
- Thread spawning and task submission
- Deep call stacks with delayed effect resolution
- Precise path feasibility analysis
- Full numeric constraint solving
- Termination analysis
- Sound modeling of arbitrary native extensions
- Perfect precision for unbounded resource creation
These are conscious exclusions, not oversights.
filename = "abc"
for s in ["a", "b"]:
with open(filename + ".txt", "w"):
write()
filename += "_" + sSidewinder records:
FileWrite("abc.txt")
FileWrite("abc_{s}.txt")
Where {s} is a symbolic template — not a variable.
No infinite chain. No path solving. No runtime simulation.
Sidewinder is for:
- static analysis researchers
- PL engineers
- tooling developers
- people frustrated with “best-effort” Python analyzers
It is not a linter. It is not a type checker. It is not a runtime.
- APIs are unstable
- abstractions are evolving
- correctness > completeness
Expect breaking changes.
Sidewinder draws ideas from:
- Abstract Interpretation (Cousot & Cousot)
- Effect systems
- Symbolic execution
- Dataflow analysis
- Real-world Python codebases (services, jobs, pipelines)
Good catch — that is the intellectual center, and it deserves to be explicit but phrased like a PL idea, not a slogan.
Here’s a revised Philosophy section that cleanly injects that grand idea without buzzwords or overclaiming. You can drop this in verbatim, or tweak tone.
Sidewinder is built around a simple but non-standard assumption:
Effects should be recorded precisely when they occur, but interpreted only when their context is known.
Instead of eagerly resolving what an operation does (e.g., which object is mutated, which file is written, which service is invoked), Sidewinder records exact symbolic effect descriptors that preserve:
- the kind of effect
- the target identity (object, attribute, key, path, service name)
- the indirection structure through which the effect occurs
Resolution is intentionally postponed until sufficient information is available (typically at call sites or concrete boundaries).
This avoids two common failure modes of Python static analysis:
- Premature over-approximation, where effects collapse too early to be useful.
- State explosion, where attempting to resolve everything immediately leads to non-termination.
Sidewinder prefers to keep effects named, structured, and composable for as long as possible, even if that means deferring interpretation.
The guiding principle is:
Track what happened exactly — decide what it means later.
Precision is allowed to degrade only when required for convergence, never by default.