fix(teleprompt): respect MIPROv2.compile seed=0

[Zsanz3]

Changes

MIPROv2.compile applied the seed with seed = seed or self.seed. In Python, 0 or self.seed is self.seed, so compile(..., seed=0) silently used the constructor default (seed=9).

The fallback is now seed = seed if seed is not None else self.seed. Only a missing/None seed uses the constructor value; seed=0 is kept.

A unit test asserts that compile(..., seed=0) calls _set_random_seeds(0).

Fixes #10321.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The change is safe to merge: it preserves an explicitly supplied zero seed while retaining the constructor fallback for None. No blocking findings remain.

Summary

MIPROv2.compile now keeps an explicit seed=0.

• MIPROv2.compile keeps zero as an explicit random seed.

_{Reviews (25) · Last reviewed commit: "Merge branch 'main' into cursor/fix-mipr..." · Reviewed by Greptile}

[VANDRANKI]

Community review, does not clear the merge gate.

Small, clear fix in dspy/teleprompt/mipro_optimizer_v2.py. compile() had seed = seed or self.seed, which is the classic Python truthy-vs-None bug: 0 or self.seed evaluates to self.seed because 0 is falsy, so calling compile(seed=0) silently ignored the caller's explicit 0 and fell back to whatever seed the constructor was given. Fixed to seed = seed if seed is not None else self.seed, which only falls back when the caller didn't pass a seed at all.

The new test mocks _set_random_seeds and _set_and_validate_datasets (raising to stop execution right after the seed line), calls compile(..., seed=0), and asserts _set_random_seeds was called with 0 specifically. That directly targets the bug rather than just checking compile succeeds.

Simple, correct, matches the referenced issue #10321. Comfortable approving.