PyneSys @pynesys

Agree on blind out of sample and cross-checking. But a TradingView backtest set up realistically isn't the weak link: turn on Bar Magnifier and add real costs. Bad results usually come from zero costs, repainting or lookahead scripts, and those break a Python backtest just as easily.

@ChallengerFxFr I like the random benchmark with the same trades. So it beats random timing on H1 but still loses to buy and hold. Good to see someone actually measure that. We ran the SuperTrend strategy on our engine too, it matched TradingView on 669 of 669 trades.

Every chapter is getting its own 5-10 minute video. The first ones are up, more are coming: youtube.com/playlist The book is available in 12 languages.

In the background PyneCore runs your code one candle at a time, with Pine Script semantics. On the 1,000 most popular public TradingView scripts its output is 99.77% bit-identical with TradingView: wild.pynesys.io

We wrote a free book for people who want to code their own trading indicators and strategies but have never programmed. No Pine Script or Python needed. You learn Pyne code from your first variable to a backtested strategy. pynecore.org/learn

Other runs: 91 s to 20 s, and 126 s to 9 s. Output did not change. On the tested scripts it is identical, bar for bar. pynesys.io/news

The hardest part was the dependency analysis. Too cautious, and it chained every request to every other one, forcing them to run in sequence. Removing those false links alone took one community indicator from over 2 minutes to 9 seconds.

request.security used to be the slowest part of a PyneCore backtest. Each call runs in its own background process. That process ran the entire script on every bar to produce one value.

Step 5 is the one I'd never skip. Matching a few months is easy, matching years of trades is where two engines usually drift apart. When they don't match, it's mostly fills inside the bar, commission and slippage settings, or how much history each side used. On TradingView, turn on Bar Magnifier so fills use lower timeframe data, and use Deep Backtesting to cover the full history, since the normal chart only loads a limited number of bars.

Good point, and one people rarely check. TradingView has a built-in answer for it: if the high is closer to the open than the low, it assumes the bar went open, high, low, close, otherwise open, low, high, close. That's a sensible guess, but still a guess. Turning on Bar Magnifier makes it use lower timeframe bars to settle the order. If the result changes a lot with it on, the edge was living inside those ambiguous candles.

The math is where it drifts. Tiny float differences accumulate, and anything with variance or stdev blows them up. Indicator algorithms aren't set in stone either: many variants, different warm-ups, different order of operations. Then the quirks: on TradingView, crossover compares to the last bit, so a 1 ULP difference fires a signal, while < and > round. Matching a short chart by eye is easy. Matching it over years of data is the hard part.

Nice tool. One thing I'd add from experience reproducing TradingView's results: TA-Lib doesn't match TradingView's built-ins. Different warm-up, different defaults, and some functions just compute differently, so the local numbers drift from what Pine shows. On top of that, an optimizer is very good at finding exactly those gaps, plus intrabar fill differences. So the "best" parameters can partly be an artifact of the simulator. I couldn't get matching results with any Python tool, which is why I ended up writing PyneCore. Either way, I'd run the top few sets back on TradingView itself, with real commission and slippage, before trusting them.

The request.security one is sneaky because the code looks fine, whoever wrote it. lookahead_on without the [1] offset hands the strategy the higher-timeframe close before it exists, and the backtest looks amazing. Another common one is process_orders_on_close=true, which fills at the close of the bar that made the signal. You can't get that price live. None of this is the tester's fault. It does exactly what the script tells it to.

That comparison is actually very close to what I've been working on for years. I built PyneCore, an open-source Python runtime designed to reproduce Pine Script's behavior, including TradingView's strategy execution model. Existing Pine scripts can be converted with PyneComp, which saves maintaining a separate Python implementation by hand. I've put a lot of work into matching TradingView closely, and the comparison results are public. Given that you're already using both, it might be useful for your workflow.

Classic multi-TF gotcha. With the default lookahead_off you're not guaranteed the last closed HTF bar: history shows confirmed values, but live you get the still-forming one, so chart and alert disagree. The fix on TradingView is counterintuitive: request.security(syminfo.tickerid, "D", close[1], lookahead=barmerge.lookahead_on). You turn lookahead ON to avoid lookahead, and the [1] keeps it honest. It works, but it confuses everyone. In PyneCore I added barmerge.lookahead_last_closed for exactly this: it always gives the last closed HTF bar, in backtest and live, no tricks needed.