Pine Script Compatibility link

PyneCore runs Pyne code: Python whose API and bar-by-bar semantics follow TradingView’s Pine Script v6, with results that match TradingView. This page lists how completely the Pine Script v6 API is covered, how closely the results match, and where PyneCore differs on purpose.

Running existing Pine Script: PyneCore does not read Pine Script source itself. Existing scripts are converted to Pyne code by PyneComp, the PyneSys compiler for Pine Script v4, v5 and v6 (v1–v3 sources are converted too, on a best-effort basis). PyneComp is a separate service that needs a PyneSys API key; with the key configured, pyne compile script.pine converts a script, and pyne run script.pine converts it before running — see Compiling Pine Scripts.

The match with TradingView is measured, not assumed: published TradingView scripts are converted with PyneComp, run by PyneCore, and every comparable output is compared with TradingView’s own.

Validation status — snapshot 2026-10-01, Pyne in the Wild

• 920 published open-source TradingView scripts (462 indicators, 458 strategies; Pine Script v4: 320, v5: 341, v6: 259), all converted and run
• 1,241 / 1,241 outputs comparable with TradingView verified (812 plot outputs, 429 strategy trade lists)
• 99.768% of 117,659,091 plotted values identical to TradingView to the bit; the largest relative gap anywhere is 1.2 × 10⁻¹⁰ (about 9 significant figures)
• 318,982 strategy trades in 429 strategies: entry and exit timing and trade counts match
• Chart: BINANCE:BTCUSDT, 30-minute bars; per-script results and methodology are public

Status Legend link

Technical Analysis (ta) link

Strategy Simulator link

Request Module link

request.security() Details link

Drawing Objects link

Every drawing API is implemented: objects are created, updated, deleted and read back exactly as in Pine Script, and their state rolls back with the bar on intra-bar re-execution. pyne run --viz exports plots and drawings as NDJSON (--viz-journal adds a per-bar create/update/delete event log) for any charting front end — see Visual Output. PyneCore itself draws no chart.

Core Modules link

Type System link

Enum Constants link

All Pine Script v6 enum constants are implemented:

Pine Script Syntax Features link

Not Applicable to PyneCore link

These Pine Script features exist only in TradingView’s live charting environment and have no equivalent in PyneCore:

No lookahead, ever link

PyneCore is a backtest and live-trading runtime, not a chart-analysis tool. Where TradingView hands a script data the bar could not have known yet, PyneCore diverges from TradingView on purpose and returns what was actually knowable at that moment.

The reasoning is asymmetric. On a chart, repaint is visible and recoverable — you watch it happen and re-read the chart. In a backtest it silently inflates results, and in a live bot it produces decisions the market never supported. A loud, safe divergence beats a quiet, dangerous match, so this rule outranks TV parity everywhere it applies.

Note what is not affected: the canonical daily-pivot idiom request.security(sym, "D", close[1], lookahead_on) lives entirely in close[1], reads a period that has genuinely closed, and matches TradingView exactly. Only the bare form — which is future data on every chart bar except a period’s last — differs.

barmerge.lookahead_last_closed is a PyneSys-native mode for stating “last closed” intent explicitly, without relying on the TV close[1] idiom at all.

The same rule governs every body execution that stands mid-bar. calc_on_order_fills re-runs the body when an order fills, and calc_on_every_history_tick runs it at every point of the bar the broker emulator walks: without the magnifier the four assumed nodes — open, the extreme nearest the open, the other extreme, close — and with it, the end of every sub-bar. TradingView hands all of those passes the bar’s finished OHLCV, so a pass standing at the open can already read the high that only happens later; PyneCore gives each pass the bar truncated to its own point, with volume accrued to match and hl2 / hlc3 / ohlc4 / hlcc4 recomputed from the truncated values. Only the bar’s last, definitive execution sees the completed bar — which is also the only execution a strategy without these flags ever gets, so default strategies are unaffected.

Known TradingView quirks not reproduced link

Behaviour that looks like a TradingView defect rather than a rule is documented here instead of being copied. Each entry says where to look if a script ever turns out to depend on it.

Session mask on the day before a fall DST change link

On the day BEFORE a timezone’s fall clock change — where no offset shifts at all — TradingView appends one extra hour to the intraday close of every session run that has an endpoint on the changing wall-clock hour (02:00 in America/New_York and Europe/London, 03:00 in Australia/Sydney). On the first chart bar of that extra hour time(tf, session, tz) returns na while time_close(tf, session, tz) returns a value, so the same bar is out of and in the session at once. PyneCore returns na from both.

Measured on a 60-minute chart, 2024-01 to 2026-09, identically on BINANCE:BTCUSDT, COINBASE:BTCUSD, BITSTAMP:BTCUSD, KRAKEN:XBTUSD and CAPITALCOM:BTCUSD, so it does not depend on the data source:

It can only show on an instrument that trades on that day (the day before the change is a Saturday, or a Friday evening UTC for Sydney), which rules out exchange-traded and FX symbols, and only in a script that reads time_close() with such a session: the usual na(time(tf, session, tz)) test agrees with TradingView on that bar. It is one bar per affected session per year.

Where to look: _session_occurrences_opening_on and _intraday_session_bounds in pynecore/lib/__init__.py. Both functions read one session occurrence per bar, so reproducing the quirk needs a rule of its own for time_close() on that single bar.

Precision link

What “matches TradingView” means, measured on the validation corpus (snapshot

• Plotted values: 99.768% of 117,659,091 values are identical to TradingView to the bit. In 794 of the 811 compared plot outputs every single value is bit-identical. The largest relative gap anywhere is 1.2 × 10⁻¹⁰ (about 9 significant figures).
• Strategy trades: 318,982 trades in 429 strategies; entry and exit timing and trade counts match TradingView in every one of them.
• OHLCV data: the v2 .ohlcv format stores int64 millisecond timestamps, float64 open and volume, and high/low/close as float32 deltas from the open — promoted to float64 whenever a delta cannot hold the symbol’s tick grid exactly — and snaps prices back to the tick grid on read.

Where the non-identical values come from link

IEEE-754 leaves implementations free to differ on operation ordering and internal precision, so two correct implementations of the same formula can produce results that differ by a few ULPs. The values that are not bit-identical differ far below any price tick: the largest relative gap in the whole corpus is 1.2 × 10⁻¹⁰, and typical disagreements are 1e-15 to 1e-12 absolute, adding up to at most a fraction of a percent equity drift over thousands of trades.

The disagreement is invisible in arithmetic but matters at exact-equality comparisons, where one side may see a == b while the other sees a slightly above or below b. At those sub-tick scales the difference is numerical noise, not a real trading signal. The functions most exposed to it are ta.crossover and ta.crossunder, which follow Pine’s strict-comparison spec (> / <=) and therefore inherit any boundary disagreement TradingView and PyneCore have on the same bar. Any user code that compares two computed series with ==, !=, >, < etc. without an explicit tolerance is subject to the same kind of ULP-level disagreement; if the result matters, round the operands to a meaningful number of decimal places or use math.isclose.

Resolved limitations link

Limitations that older pages, issues and articles may still mention, with the release that closed them:

• v6.4.1 — bar magnifier and calc_on_order_fills.
• v6.5.1 — multi-period D/W/M aggregation (2D, 3W, …) is trading-day and holiday aware (#65).
• v6.5.2 — multi-day request.security exposes the last confirmed period, not the developing one (#70).
• v6.5.3 — nD/nW/nM aggregation follows exchange holidays and session schedules, e.g. on CME futures (#71).
• v6.6.0 — live data (pyne run --live), broker trading (pyne run --broker) and realtime barstate flags; plot and drawing export (pyne run --viz).
• v6.10.3 — extended trading hours: SymInfo keeps the symbol’s pre-market and post-market template, time(tf, "extended") / time(tf, "regular") read it, and on bars of the extended hours session.ispremarket, session.ispostmarket, session.ismarket, session.isfirstbar / session.islastbar and syminfo.session behave as on TradingView (see Extended Trading Hours). CFD feeds without an exchange calendar (Capital.com) count every weekday on the nD/nW/nM grid, as TradingView does.