Skip to content
Axint

Parity with TypeScript

The Python SDK is parity-bound to the TypeScript SDK — every feature the TS surface exposes will eventually be available in Python, because both speak the same language-agnostic Intermediate Representation.

Supported today (0.1.0a1)

  • define_intent() — all required and optional fields
  • param.* — every parameter type, including optional and default
  • entitlements — list of entitlement identifiers
  • info_plist_keys — list of Info.plist usage keys
  • is_discoverable — flag for Siri/Shortcuts discoverability
  • Multi-intent files — parse any number of intents from a single .py file
  • IntentIR.to_dict() — emits the exact camelCase JSON schema the TS compiler consumes
  • IntentIR.from_dict() — round-trip IR JSON back into dataclasses
  • CLI: axint parse, axint compile (via TS handoff)

Ships in 0.3.0

  • Direct Swift codegen — currently axint compile shells out to @axint/compiler. In 0.3.0 the Python package will ship its own generator so it works without Node.
  • Return-type inference — walking Python function bodies for return statements, the same trick the TS compiler does.
  • MCP server — python -m axint.mcp will start an MCP server for AI assistants that prefer Python.
  • Deeper validator integration — running the full AX100-series validator rules on Python-authored intents.

Won’t ever support

  • Arbitrary Python expressions as parameter values. The parser is deliberately AST-only and never executes user code. If you write param.string(compute_description()), the parser will flag AXP007 because compute_description() isn’t a string literal. This is a safety feature, not a limitation.
  • Runtime performance of perform(). Axint is a compile-time tool — the perform() body never runs in Python. It gets transpiled to a Swift stub that you implement yourself.