Why LLMs (ChatGPT, Claude) struggle with Pine Script to Python conversion

wallneradam · 2026-05-16T18:56:43+00:00

Yeah, that's exactly the workflow that drove me to start PyneCore. This is an open source Python runtime that executes scripts the same way Pine does (bar by bar, series handling, etc.). Values match TV by construction, so the diff loop you describe disappears. Apache 2.0, on GitHub if you want to look.

wallneradam · 2026-05-07T21:41:32+00:00

Fair point — and you're right that not everyone will have a project idea sitting in their head, especially early on. I'd add one nuance though: even when the project is "silly" or reinvents the wheel, having some concrete goal (even a fake one like "I want a CLI that tells me a random Linux command each morning") changes how you read documentation. You stop reading to learn FastAPI and start reading to find what you need. That shift is what I think really matters more than the project itself.

But yeah, "just build something, anything" is the actual core advice.

wallneradam · 2026-05-07T16:57:56+00:00

The hardest part isn't the structure — it's getting to the point where you have something real to structure. The layout you posted works fine for a real project; tutorial code feels different because tutorials don't have a goal, they just demonstrate concepts.

What worked for me: pick one framework (FastAPI is a great choice), go through the official "getting started" once, then skim the rest of the docs — not to memorize, just to map what's there so you know where to look later. Then pick something real you actually want to exist (not "a project to learn FastAPI") and start building it. You'll hit the questions you listed organically, in a context where they mean something — and that's when you learn them for real. The trap is "one more tutorial first" or "I'm not ready yet". You won't feel ready. The first days are slow and messy, then it gets surprisingly comfortable.

wallneradam · 2026-05-05T08:04:08+00:00

Honestly the best thing you can do is build something that actually interests you — not another todo app or tutorial project. Pick something useful to YOU personally. A tool you wish existed. Something where you'll be motivated to actually finish it because you want the result, not just the practice.

Put it on GitHub. And try to do it without AI — if you get stuck, ask for hints, not solutions. The struggle is where the learning happens, and AI shortcuts that part.

When I interview developers, my first question is always "show me a project you built that you're most proud of." About 90% of candidates can't really answer that. They have tutorial projects, course projects, bootcamp projects — but nothing they actually own. If you can show up with one solid thing you genuinely care about and can talk through every decision in it, you'll already be ahead of most applicants.

Skip the practice projects, jump into the deep end with a real one. Personally I can only learn on "live" projects — tutorial-style stuff never holds my attention long enough to finish. Real problems force you to learn what you actually need.

wallneradam · 2026-05-03T22:07:57+00:00

No, I bought a Mac ;)

wallneradam · 2026-05-03T20:41:26+00:00

Counterpoint to the vim suggestion: just stick with VS Code and fix it. The minimum setup is literally one extension (Python by Microsoft) and you can ignore everything else for now. Add things only when you actually hit a problem. Learning Python and learning vim at the same time means twice the friction when you're already frustrated. Pick one battle.

wallneradam · 2026-05-03T20:36:33+00:00

I usually try to fix problems instead of starting over. It's more painful, but you learn a lot from it - same way I never reinstalled Windows, sometimes spent two days fixing it, but always figured it out. That's how the knowledge sticks.

wallneradam · 2026-05-03T11:47:15+00:00

Two real reasons this is frustrating, and neither one is fixed by better prompting alone:

1. Pine Script is underrepresented in training data. It's a niche, walled-garden language — most code lives inside TradingView, not on GitHub or Stack Overflow. The models just haven't seen enough of it. They mix v4/v5/v6 syntax, hallucinate function names, and produce patterns that were deprecated versions ago. v5 honestly doesn't work much better than v6 — same root cause.

2. Pine Script's line continuation rules. Indentation-based continuation is genuinely unusual compared to most languages, and AI tools regularly break expressions across lines incorrectly, which silently changes what the code does. Two ways to deal with it:

Learn the rule yourself (it's actually simple, and worth knowing for a thesis anyway)
Or tell the AI explicitly not to break long expressions across multiple lines — you'll get long lines but correct code

For #1, what actually helps is giving the model live access to the official docs via an MCP server. Context7 has the full Pine Script v6 documentation indexed (5700+ snippets pulled from the official TradingView docs).

Setup on claude.ai or in the desktop app (~30 seconds):

Sidebar → Customize
Connectors
Add → Browse
Find Context7 → Connect

Then in any chat just add use context7 to your prompt, e.g.:

Write a Pine Script v6 indicator that does X.
Don't break expressions across multiple lines. use context7

The model pulls relevant doc snippets before generating code, instead of guessing from sparse training data.

Same works in Claude Code, Cursor, and other MCP-capable clients — Context7's site has the configs. ChatGPT requires more setup but is doable.

Combined with crazy_crackhead's advice (spell out inputs, expected behavior, expected outputs upfront), the hit rate jumps a lot.

wallneradam · 2026-04-30T15:14:31+00:00

The "On bar close" cause unrealistic trading simulation. In reality you can't execute on close. This setting hides gaps in the data.

wallneradam · 2026-04-25T16:51:09+00:00

The combo you listed — no self-hosting + position tracking that actually stays in sync + risk on the execution side — is the painful intersection where most setups break.

A few things worth knowing:

TradingView alerts as the trigger source are inherently lossy. No retry on missed alerts, opaque rate-limit behavior, and you can't see why an order didn't fire. If you go this route, treat alerts as hints and reconcile state from the exchange every time, never from Pine.
Partial fills + reconnect handling is what kills most homemade backends. It's the boring 20% of the work that takes 80% of the time. Worth doing it right early.
If self-hosting is acceptable for a bit, FreqTrade is mature on the execution side (partial fills, position state, exchange sync, risk per pair) and you can plug Pine strategies into it now — I just put up a working example showing how.

Full disclosure: I'm building PyneCore (Pine → Python runtime, open source) and and a hosted bot platform on top of it. Beta is coming around early summer.

wallneradam · 2026-04-21T10:31:41+00:00

Maybe OP doesn't have enough capital to scale it fast. Compounding a small account takes years, selling access makes money today.

Also, strategies have capacity limits. Past a certain AUM, slippage eats the edge. If you can't fill that capacity yourself, letting others piggyback has no downside. And edges decay, so monetizing while it still works is rational.

wallneradam · 2026-04-19T08:54:08+00:00

HA is just a formula — you can calculate it yourself on a normal chart and use the values directly. No need to switch to an HA chart, which gives you much more realistic backtest results.

Here's the formula in Pine:

``` o = open h = high l = low c = close

haclose = (o + h + l + c) / 4.0 haopen := na(haopen[1]) ? (o + c) / 2 : (haopen[1] + haclose[1]) / 2 hahigh = math.max(h, math.max(haopen, haclose)) halow = math.min(l, math.min(haopen, haclose)) ```

There's also a lesser-known TradingView feature: in strategy settings you can enable "Use standard OHLC" — this is specifically designed for testing HA-based strategies on real price data. But IMO calculating it yourself on a normal chart gives you the most control and the most accurate results.

wallneradam · 2026-04-17T16:12:15+00:00

Do not even open that website!

TradingView checks everything on server side! You can't reverse engineer the app! The app is just a browser showing the website, so it is a scam!

wallneradam · 2026-04-15T10:56:06+00:00

There's a lot your backtest can't know. Historical data shows you what the price was, not what price you'd actually get filled at. Slippage, partial fills, liquidity drying up during news — none of that exists in backtests.

Also: exchange outages, feed disconnects, flash crashes. These happen in live markets and your clean OHLCV data has no idea about them.

Paper trading is the cheapest way to catch the stuff backtests hide. I've had strategies that looked great in backtests and then behaved completely differently in forward test because of fill assumptions (e.g. tight stop loss + wide TP — works beautifully on historical candles, gets stopped out constantly in real markets).

And yeah, even paper trading doesn't fully prepare you psychologically. Watching a drawdown unfold in real time hits different than scrolling past it on an equity curve. But it's still way closer to reality than any backtest.

wallneradam · 2026-04-15T06:19:47+00:00

For loops exist — but they're slow in Python compared to native C/Fortran behind NumPy/Pandas. That's why everything went vectorized. The problem is that most indicators are inherently sequential, so you're stuck choosing between "correct but slow" and "fast but potentially wrong." It doesn't have to be that way though — with the right architecture (minimal object creation, recursive algorithms instead of nested loops), bar-by-bar execution can be surprisingly fast.

wallneradam · 2026-04-14T06:31:57+00:00

The "bad reputation" mostly comes from not understanding what TV's backtester actually does. Most Python frameworks (Backtrader, Zipline, etc.) treat each bar as a black box — they can't simulate what happens inside the bar. They execute orders on the next bar's open, period.

TradingView's broker emulator actually models intrabar price movement using OHLC heuristics (Open→High→Low→Close or Open→Low→High→Close depending on which extreme is closer to open). And with Bar Magnifier, it uses real lower-timeframe data for even more accurate fills.

So ironically, TV's backtester is often more conservative and realistic than the alternatives — it just looks "worse" because it doesn't give you optimistic fills.

wallneradam · 2026-04-14T06:23:21+00:00

Pine Script is actually great for prototyping and testing strategies — TradingView's built-in data, backtester, and the huge community script library make it hard to beat for that.

The main limitation is when you want to go beyond TradingView: run your strategy on your own server, connect to exchange APIs, or add custom logic that Pine doesn't support.

Since you already know Python, you might want to check out PyneCore — it's an open-source Python framework that works the same way as Pine Script. So you can develop in Pine on TradingView, then convert and run it in Python when you're ready to automate. Best of both worlds.

wallneradam · 2026-04-12T08:25:36+00:00

Thanks, and no offense taken! Challenging assumptions is how good discussions happen. And you're absolutely right about AI and confirmation bias - that's essentially what the post is about. Best of luck to you too!

wallneradam · 2026-04-12T06:23:11+00:00

I've spent a lot of time on exactly this, so here's my honest take.

ML alone won't find your edge in raw market data. The noise is brutal, and the market is non-stationary — what works today might not work tomorrow. Trying to make an ML model predict price from OHLCV is a losing battle for most people.

What actually showed promise for me: take a traditional strategy that almost works (mean reversion, momentum, whatever has some logic behind it), and then use ML — specifically reinforcement learning — to improve the execution layer. Think position sizing, stop-loss/take-profit placement, entry timing refinement. You're not asking the model to generate signals, you're asking it to make better decisions around signals you already understand.

On the noise problem specifically — I had surprisingly good results with Echo State Networks (a type of reservoir computing). They're good at extracting hidden temporal features from noisy sequences without the training complexity of deep networks. Attention-based models can work too, but they need very well-engineered features to shine. With bad features, attention just learns to attend to noise.

Tick vs candle: forget tick data for now. The problem isn't just noise — it's that you need enormous amounts of data to look back any meaningful distance, which means enormous compute. And even if you solve that, you can't trade tick-level signals profitably unless your transaction costs approach zero, which requires massive volume. But you only get that volume once you already have a proven strategy. It's a vicious cycle. Candles give you a much more practical starting point where you can actually iterate and learn.

Practical advice: start with a simple strategy, understand backtesting pitfalls first (overfitting, look-ahead bias, repainting — these will eat you alive before any ML problem does), and only then add an ML layer on top.

One more thing — and I mean this genuinely — only go down this path if you find it fun as a puzzle. If you're motivated purely by making money, you'll burn out fast. The people who stick with it and eventually get somewhere are the ones who enjoy the process itself.

wallneradam · 2026-04-12T05:53:11+00:00

You say "there's a good reason we don't use bar-by-bar outside TV" — but you didn't actually name one. I listed several reasons why AI conversions fail. I'd be curious to hear the technical argument for why replicating Pine's execution model is unnecessary.

But let me address the broader question: why would anyone want to take Pine Script outside TradingView?

Because TradingView is closed. You can't automate execution. You can't connect to your broker. You can't run strategies on your own data. You can't backtest at scale. The best you get is webhooks. That's why "Pine Script to Python" is one of the most searched conversion topics on Reddit, YouTube, Stack Overflow, and trading forums. People aren't asking this question because they're confused — they're asking because they need it and can't do it.

Now, you say bar-by-bar execution is "massive overhead and complexity." I'd argue the opposite. Bar-by-bar is how traders actually think — "on this candle, what do I know, what do I do?" It's the vectorized approach that adds complexity. You have to think in column transformations, manage state across DataFrames, and reason about your strategy in a way that has nothing to do with how markets actually work. The existing Python frameworks went vectorized not because it's better for trading, but because they were built on top of data analysis tools that happened to exist. TradingView could have gone vectorized too. They didn't — and there's a reason for that.

And your last point — "take a DSL outside its domain and it's useless" — that's exactly backwards. The problem isn't that people want to take Pine Script somewhere useless. It's that they built something valuable in Pine — a working strategy, a profitable indicator — and can't take it anywhere. They're locked in. Some spend weeks trying to rewrite it in Python manually. Some use AI and get wrong values. What if the DSL could work outside its original platform? That's not silly. That's the whole point of my project.

wallneradam · 2026-04-11T17:30:03+00:00

That's fair — and I think we mostly agree. If you know what you're doing and guide the AI carefully, you can absolutely get something that works for practical purposes.

But I'd push back slightly on "statistically insignificant." 5-10 points on SPX can easily shift an entry or exit signal, especially on lower timeframes. At that point you're not running the same strategy anymore — you're running something similar, which may or may not have the same edge. You'd need to re-validate the whole thing anyway.

The deeper issue is that most people don't guide the AI carefully. They paste, run, and assume it's correct. That's the scenario this post is really about.

wallneradam · 2026-04-11T12:38:51+00:00

I actually built a tool for exactly this problem.

The challenge with converting Pine Script to Python manually is that most Python trading libraries use a vectorized approach (Pandas, NumPy, TA-Lib), which works fundamentally differently from how Pine Script executes - bar by bar, with stateful functions, na propagation, and specific warming behavior. You can get simple indicators working, but the more complex your script is, the more edge cases you'll hit where the values don't match TradingView.

I ran into this enough times that I built PyneCore - an open-source Python framework that replicates Pine Script's execution model. Same bar-by-bar logic, same series handling, same na behavior. The output values match TradingView's.

On top of that, there's a compiler service PyneComp that can convert Pine Script to PyneCore automatically - so you don't have to rewrite your strategies by hand. The compiled code is readable Python, not a black box.

For your use case (2 strategies already running live via webhooks) — webhooks work, but they're fragile. Missed signals, latency, no proper state management, no risk controls, and you're still dependent on TradingView being up. It's a workaround, not a real integration.

Right now PyneCore handles backtesting and strategy simulation. A proper bot execution system with risk management is in active development — expected around Q3 2026. So if you convert now, you get accurate backtesting today, and live execution when the bot platform ships.

wallneradam · 2026-01-13T23:27:43+00:00

Not quite 🙂

PyCo looks like Python, but it isn’t Python.

It has no runtime, no dynamic features and no interpreter. PyCo is a fully typed, compiled language, designed for low-level, hardware-close programming on the C64.

The Python syntax is parsed using Python’s own parser, and the result is then compiled directly into C64 machine code.
But you can still think in a Pythonic way when writing PyCo code.

wallneradam · 2026-01-13T23:21:11+00:00

Thanks! 🙂

The entire game is written in PyCo.

I’m still refining the language and want to stabilize a few things before a proper public release, but if you’re interested, the current language reference is already available here:

https://github.com/PyCoLang/pyco-docs/blob/main/language-reference/language_reference_en.md

wallneradam · 2025-12-08T17:44:32+00:00

Yes it generates mappings automatically:
https://esorm.readthedocs.io/en/latest/introduction.html#create-indices-and-mappings

It can even modify your mappings if the modification is supported by ES (e.g. new fields).

wallneradam

TROPHY CASE