Nit
The KWS examples validate the KWS_CLASSES env knob with a module-level assert:
NUM_CLASSES = int(os.environ.get("KWS_CLASSES", "6"))
assert NUM_CLASSES in (6, 35), NUM_CLASSES
assert is stripped under python -O / PYTHONOPTIMIZE, so the validation silently vanishes in optimized runs (an invalid KWS_CLASSES would then fail later with a confusing error).
Fix
Replace with an explicit guard that always runs:
if NUM_CLASSES not in (6, 35):
raise ValueError(f"KWS_CLASSES must be 6 or 35, got {NUM_CLASSES}")
Affected files
examples/kws_mfcc/{prepare_data,train_pytorch,compare}.py
examples/kws_raw/{prepare_data,train_pytorch,compare}.py
(The C trainers already use an explicit if … fprintf … return default in readNumClasses(), so only the Python side needs this.)
Low priority — CI does not pass -O, so this is robustness/hygiene, not a live bug. Surfaced in the PR #256 final review.
Nit
The KWS examples validate the
KWS_CLASSESenv knob with a module-levelassert:assertis stripped underpython -O/PYTHONOPTIMIZE, so the validation silently vanishes in optimized runs (an invalidKWS_CLASSESwould then fail later with a confusing error).Fix
Replace with an explicit guard that always runs:
Affected files
examples/kws_mfcc/{prepare_data,train_pytorch,compare}.pyexamples/kws_raw/{prepare_data,train_pytorch,compare}.py(The C trainers already use an explicit
if … fprintf … return defaultinreadNumClasses(), so only the Python side needs this.)Low priority — CI does not pass
-O, so this is robustness/hygiene, not a live bug. Surfaced in the PR #256 final review.