feat(cli): python

[ErnestM1234]

add python registration support: t('hello, {name}', name='john', _max_chars=10), also supports declare_static()/declare_var() syntax

Greptile Summary

This PR adds Python translation support to the CLI, introducing a new @generaltranslation/python-extractor package and wiring it into the existing push pipeline. It handles t('hello, {name}', name='john', _max_chars=10) call extraction along with the declare_static() / declare_var() DSL for static and runtime variable interpolation. The refactored shared post-processing utilities (calculateHashes, dedupeUpdates, linkStaticUpdates) are a clean improvement that eliminates duplication between the React and Python pipelines.

Key changes:

• New python-extractor package: tree-sitter-based AST extraction of t() / msg() calls from Python source files, including cross-file helper resolution and cartesian expansion of declare_static variants.
• Framework auto-detection for pyproject.toml, requirements.txt, and setup.py using proper parsers.
• createPythonInlineUpdates CLI integration, routed via isPythonLibrary type guard in translation/parse.ts.
• calculateHashes / dedupeUpdates / linkStaticUpdates extracted to a shared extraction/postProcess.ts.

Issues found:

• resolveFunctionInFile in resolveFunctionVariants.ts uses synchronous fs.readFileSync inside an async function, blocking the event loop during cross-file resolution. It should use fs.promises.readFile.

Confidence Score: 4/5

• Safe to merge after addressing the blocking synchronous file I/O in cross-file resolution.
• The core extraction logic is well-tested with a comprehensive fixture suite, and the refactored post-processing pipeline is a clean improvement. The one flagged issue (synchronous file read in async context) is a quality/performance concern rather than a functional blocker for the common extraction path. The fix is straightforward and isolated to one location.
• packages/python-extractor/src/resolveFunctionVariants.ts (replace fs.readFileSync with fs.promises.readFile on line 67)

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["CLI push command\n(translation/parse.ts)"] --> B{"isPythonLibrary?"}
    B -- yes --> C["createPythonInlineUpdates\n(python/parse/)"]
    B -- no --> D["createInlineUpdates\n(react/parse/)"]

    C --> E["matchFiles\n(.py glob)"]
    E --> F["extractFromPythonSource\n(python-extractor)"]
    F --> G["extractImports\n(GT import aliases)"]
    G --> H["extractCalls\n(t / msg calls)"]
    H --> I{"hasStaticHelpers?"}
    I -- yes --> J["parseStringExpression\n(StringNode tree)"]
    J --> K["resolveDeclareStaticArg\n/ resolveDeclareVarArg"]
    K --> L["resolveFunctionCall\n(cross-file resolution)"]
    L --> M["resolveFunctionInFile\n(crossFileCache)"]
    I -- no --> N["extractStringContent\n(plain string)"]
    J --> O["nodeToStrings\n(cartesian expand)"]
    N --> P["ExtractionResult[]"]
    O --> P
    P --> Q["mapExtractionResultsToUpdates"]
    Q --> R["calculateHashes"]
    R --> S["dedupeUpdates"]
    S --> T["linkStaticUpdates\n(sharedStaticId)"]
    T --> U["Updates[]"]

Loading

Comments Outside Diff (1)

1. python-extractor-detailed-plan.md, line 1 (link)

   This detailed plan document is committed to the repo root and is now stale. Its "Phase 2 (Future)" section lists declare_static, declare_var, and msg() support as not yet implemented, but this PR implements all three features.

   Committed design documents tend to drift out of sync and can mislead future contributors. Consider removing this file or relocating it to a docs/ or .github/ directory if you want to preserve it as a living design reference.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: python-extractor-detailed-plan.md
   Line: 1
   
   Comment:
   This detailed plan document is committed to the repo root and is now stale. Its "Phase 2 (Future)" section lists `declare_static`, `declare_var`, and `msg()` support as not yet implemented, but this PR implements all three features.
   
   Committed design documents tend to drift out of sync and can mislead future contributors. Consider removing this file or relocating it to a `docs/` or `.github/` directory if you want to preserve it as a living design reference.
   
   How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 57ce390}

Greptile also left 1 inline comment on this PR.

[ErnestM1234]

@greptileai plz re-review

[archie-mckenzie]

@greptile-ai re-review

[ErnestM1234]

@greptileai plz re-review

[ErnestM1234]

@greptileai plz re-review

[archie-mckenzie]

@greptile-ai re-review

[archie-mckenzie]

@claude review pls

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[greptile-apps]

resolveFunctionInFile is async but uses synchronous fs.readFileSync() to read files. This blocks the Node.js event loop during cross-file helper resolution, which can cause noticeable stalls when projects have deep re-export chains.

Use fs.promises.readFile to keep the function non-blocking:

Suggested change

	source = fs.readFileSync(filePath, 'utf8');
	} catch {
	crossFileCache.set(cacheKey, null);
	return null;
	}
	let source: string;
	try {
	source = await fs.promises.readFile(filePath, 'utf8');
	} catch {
	crossFileCache.set(cacheKey, null);
	return null;
	}

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/python-extractor/src/resolveFunctionVariants.ts
Line: 67-71

Comment:
`resolveFunctionInFile` is `async` but uses synchronous `fs.readFileSync()` to read files. This blocks the Node.js event loop during cross-file helper resolution, which can cause noticeable stalls when projects have deep re-export chains.

Use `fs.promises.readFile` to keep the function non-blocking:

```suggestion
  let source: string;
  try {
    source = await fs.promises.readFile(filePath, 'utf8');
  } catch {
    crossFileCache.set(cacheKey, null);
    return null;
  }
```

How can I resolve this? If you propose a fix, please make it concise.