None, Option, and Result

Python None is useful but quiet. Musi Option makes absence a branch the caller sees before touching the value.

def find_gate(ticket: str) -> int | None:
    if ticket == "A12":
        return 4
    return None

let option := import "@std/option";

let findGate (ticket : String) : option.Option[Int] :=
  match ticket (
  | "A12" => option.someOf[Int](4)
  | _ => option.noneOf[Int]()
  );

findGate("A12");

Reading None, Option, and Result from Python

On the Musi side, Musi uses option.someOf and option.noneOf when absence is expected, so callers handle the empty branch deliberately. Read the shared example through Python eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.

False friend

Do not translate null, nil, None, or undefined as a quiet ordinary value. For a Python reader, the trap is trusting runtime convention where Musi expects a visible type or effect; Musi class is closer to an explicit protocol/typeclass than a Python class with attributes and methods.

When this pays off

Use Option when a badge, ticket, receipt, search result, or lookup may honestly be missing. The Python instinct still helps here: Keep the Python habit of naming the real-world thing first.

Keep close

• Data definitions
• Patterns
• Effects