chore - investigate Python interop for progressive native lowering

[dannymeijer]

Area

• Tooling (CLI/formatter/test runner)
• Compiler (frontend/backend/codegen)

Summary

Investigate Python interop as a 0.6 research track.

The goal is to define whether Incan should support a Python-fronted workflow where Python source can be analyzed, classified, and progressively moved toward typed Incan/Rust-native output, with dynamic Python left behind explicit interop or rewrite boundaries.

This is a research chore only. It should not promise full Python compatibility or a shipped incan py command in 0.6.

Scope

• In scope:

  • Evaluate possible Python parsing/frontend options.
  • Define lowerability classifications: direct native path, needs annotations, needs rewrite, interop fallback, unsupported.
  • Sketch a possible CLI boundary for analyzing or lowering Python source.
  • Identify which dynamic Python features must be rejected, rewritten, or isolated.
  • Decide what belongs in native lowering versus an interop fallback.

• Out of scope:

  • Shipping a Python migration command in 0.6.
  • Claiming full Python semantic compatibility.
  • Implementing broad Python standard library or extension compatibility.
  • GPU or accelerator work.

• Risks:

  • Overpromising Python compatibility would turn this into a Python implementation effort.
  • A parser-only path needs clear diagnostics so users understand why some Python cannot lower natively.
  • Assisted rewrites need equivalence checks before they can be trusted.

Plan

1. Review internal research and prior experiments.
2. Compare viable parser/frontend choices.
3. Define the first lowerability report schema.
4. Validate the schema against small representative examples.
5. Draft a follow-up product issue for a later milestone if the research direction still holds.

Done when

• A short internal research note or RFC-prep note exists for Python-fronted Incan.
• The note names the preferred parser/frontend direction or explains why the choice remains open.
• The note defines lowerability categories and diagnostic expectations.
• The note explicitly states what Python semantics are not native-lowerable.
• Any follow-up product issue is created if warranted.