How I convert Pine scripts to Pyne code automatically (transpiler notes, incl. the strategy when= problem)

[ssleon228]

Hi all — I'm ssleon228. Some of you may have seen the issues I filed here earlier (#96, #97). I built Pine2Py (pine2py.com), a transpiler that converts Pine Script to Pyne code targeting the PyneCore runtime. Since this community is the runtime side of that pipeline, I wanted to share a few conversion problems I ran into — especially one that has no clean answer — and how I ended up handling them.

1. The strategy.* when= problem

Pine lets you pass a condition inline:

strategy.entry("Long", strategy.long, when = ta.crossover(fast, slow))

Pyne's strategy API has no when parameter, so a naive 1:1 translation produces code that fails at runtime. What I settled on:

• When the call sits in statement position, the transpiler desugars it into a conditional block: the whole call is wrapped in if <condition>:.
• When a when= appears in value position (where wrapping isn't possible), the argument is stripped and the transpiler emits a diagnostic telling the user that the condition was dropped, instead of silently producing wrong code.
• The invariant I test against: generated Pyne code never contains a when= argument.

To check the desugaring is actually equivalent, I ran both variants (original when= form vs. desugared if form) and compared the outputs bar by bar — they matched exactly on my test cases. One known gap: a positional (unnamed) when argument still slips through and fails loudly at runtime; fixing that properly needs per-function parameter tables, which I haven't built yet.

2. Why the output targets a patched runtime

A handful of conversion blockers turned out to be runtime-side rather than transpiler-side. I maintain a small patch set on top of PyneCore 6.10.11 (five patches, each registered with a repro), filed the two clearest cases upstream as #96 and #97, and ship the patched runtime as a download alongside the tool so converted scripts run the same way for everyone. If any of those patches are better solved upstream, I'd genuinely like to drop them.

3. How I validated (and the limits of that)

I ran the transpiler over a corpus of 1,909 public Pine scripts. In our testing, 99.7% compiled (the emitter produced Pyne code without errors) and 98.4% translated fully (no unsupported-construct diagnostics). The remaining cases are mostly exotic builtins and a few constructs where Pine's semantics don't map onto a bar-by-bar Python model without changing meaning — those get diagnostics rather than best-effort output.

If you want to try breaking it: the site gives each account 3 free conversions, no card. Hard cases and failure reports are the most useful thing you can send me — a script that converts wrong is worth more than ten that convert right.

Happy to answer questions about the transpiler side, and equally happy to hear that one of these problems has a better solution I missed.

[wallneradam]

Thanks for the write-up and for filing #96 and #97. #97 (ta.* calls in methods declared in @udt class bodies) is supported since 6.11.0. #96 was closed as not planned: TradingView itself rejects text.valign_* as undeclared identifiers in both v5 and v6 (the valid constants are text.align_*), so PyneCore rejecting them matches TradingView. Neither case needs a patched runtime on a current release.

If the other three patches fix runtime behaviour, please file them as issues with a minimal repro against the latest PyPI release. That way the fixes land upstream and nobody has to run a modified runtime.

To clear up the when= point for anyone reading: this is a Pine v5 to v6 migration question, not a gap in Pyne. when was removed from the strategy.* functions in Pine v6, and PyneCore follows the v6 API. PyneComp compiles v4 and v5 sources by migrating them to v6 first, and when= is converted as part of that, in both named and positional form, with the positional slots checked against TradingView's own converter.

On the tooling side, everyone should use whichever converter works best for them. For context: PyneComp is our own Pine-to-Pyne compiler, and it is what funds the development of PyneCore and of PyneIDE, which is fully open source (GPL-3.0). It has been developed continuously for over a year and a half. Its test system covers both compilation and execution: converted scripts are run and their results compared against TradingView, and it handles a large number of Pine quirks along the way.

One note for anyone reading along: we can only support bug reports that reproduce on an unmodified, current PyneCore. Reports from a patched build need a repro on the stock release first.

[ssleon228]

Thanks for the detailed reply, Adam — several of these corrections change what I ship, so let me go through them one by one.

#97 / P-0003 (ta. in @UDT methods):* good news, and I'll verify rather than assume. I checked PyPI: 6.11.0 is out (2026-10-25) and 6.12.1 is current. I'll re-run my 8-line repro against stock 6.12.1, and if the method-body state threading works there, I drop P-0003 from my patch set outright. That's the outcome I wanted — one less thing to carry.

#96 / P-0002 + P-0004 (text.valign_*): I accept the not-planned call, with one honest caveat. My evidence for the alias was a pynecomp probe that showed the TV frontend symbol table declaring text.valign_top, plus a corpus script (299_market-maker-models) that uses it. But if TradingView's own converter rejects valign_* in both v5 and v6, then matching TV is the correct behaviour and my alias is wrong, not a compatibility gap. I'll re-check against TV's converter directly and drop P-0002/P-0004 if your reading holds — which I expect it will.

The other patches, for the record: P-0001 is packaging only (stripping the platform .pyd files so the vendored runtime is cross-platform deterministic) — not a behaviour fix, nothing to upstream. P-0005 (module_property.py callee-base handling) is the only one left that could be a real runtime issue, and I won't file it as a vague issue: my own audit notes say no end-to-end diverging case was ever constructed for it. I'll test it against stock 6.12.1 and file only if I can produce a minimal repro; if I can't, it stays a local note, not an upstream claim.

On when=: your framing is right and I should have stated it that way — it's a Pine v5→v6 migration question, not a gap in Pyne. My desugar (statement position → if wrap, value position → strip + diagnostic) is a transpiler-side choice for v5 sources, and I'll say so plainly in the post. One genuine gap on my side: positional when still slips through because I haven't built per-function parameter tables yet. You mention PyneComp checks the positional slots against TradingView's own converter — is that slot mapping documented anywhere public? If there's a reference an independent transpiler can mirror, I'd rather copy the mapping than re-derive it by probing.

On support policy: agreed — any future bug report from me will reproduce on an unmodified, current PyneCore first. That's a fair rule and it also protects my own users from chasing patched-runtime artefacts.

Thanks again for engaging with the write-up rather than just the issues. I'll update the discussion once I've re-run the checks above.

[wallneradam]

Thanks. One request, since this thread is public: your site's FAQ, the runtime README and your blog post still say that stock PyneCore is not a supported runtime and that these two cases fail on it. As covered above, one has worked since 6.11.0 and the other is the behaviour TradingView itself has. Please check the current release before describing PyneCore's behaviour as broken in public, and update those pages. Closing this as resolved.