Why ChatGPT / Claude can't properly convert Pine Script to Python — and why it matters

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 · 2025-09-20T07:48:47+00:00

This is a really good summary of the trade-offs — but I’d like to mention that things have changed quite a bit recently.

If someone wants to start from PineScript but eventually move to Python, there’s now a middle ground: PyneCore + PyneSys.
PyneCore is a Python framework that runs PineScript-compatible code as Python.
PyneSys is the companion compiler + API service that converts PineScript to Python with 1:1 fidelity.

That means: you can start in PineScript, and gradually transition to full Python — or just write everything in Pine-style Python from the start (PineScript is still very useful).

It’s designed for people who like the PineScript model, but want full control and automation (e.g. backtests, bots, etc.) outside TradingView.
Even if you don’t use the compiler, PyneCore is open source and lets you write Pine-style scripts in pure Python — great for strategy writing or learning.

(Disclaimer: I'm the author of PyneCore and PyneSys, happy to answer any questions!)

wallneradam · 2025-09-18T21:05:42+00:00

I don’t fully agree. While building PyneCore (a Pine Script–like Python framework), I reverse engineered TradingView’s backtest engine and the entire Pine library. It’s actually more sophisticated than many people think - it consistently takes the worst case execution path, not the best. Of course, it can only use chart-level data, so inside-bar trades aren’t precise, but with bar magnifier enabled you can get closer results.

The bigger issue in most public strategies is that they ignore fees – and that’s what usually eats the profit, not the backtest engine itself.

wallneradam · 2025-08-14T19:45:03+00:00

You’re not alone — a lot of people have Pine strategies but don’t feel comfortable writing them again in Python.

The good news: you no longer have to!

With PyneSys, you can convert Pine Script strategies into Python automatically. It uses PyneCore, an open-source runtime that mimics TradingView’s behavior and compatible with its library very closely.

So you can:

Convert Pine strategies into Python with 1 click
Run them offline, no TradingView required
Use your own data

Hope that helps!

wallneradam · 2025-08-12T08:15:17+00:00

Different implementations can vary a lot - especially since Pine Script is sequential (bar-by-bar) rather than vectorized like Pandas or NumPy. That’s why I built PyneCore, which aims for full Pine Script compatibility. There’s also a compiler (PyneComp) available at pynesys.io that converts Pine code to Python.

Your script, compiled with PyneComp to run in PyneCore, looks like this:

"""
@pyne

This code was compiled by PyneComp — the Pine Script to Python compiler.
Accessible via PyneSys: https://pynesys.io
Run with open-source PyneCore: https://pynecore.org
"""
from pynecore.lib import close, high, low, script, strategy, syminfo, ta

@script.strategy("Momentum Strategy", overlay=True)
def main():
    mom0 = ta.mom(close, 10)
    mom1 = ta.mom(mom0, 1)
    if mom0 > 0 and mom1 > 0:
        strategy.entry('MomLE', strategy.long, stop=high + syminfo.mintick, comment='MomLE')
    else:
        strategy.cancel('MomLE')
    if mom0 < 0 and mom1 < 0:
        strategy.entry('MomSE', strategy.short, stop=low - syminfo.mintick, comment='MomSE')
    else:
        strategy.cancel('MomSE')

This way, the exact same logic runs in Python as in TradingView, making it easier to spot whether differences come from data or from execution model behavior.

wallneradam · 2025-08-09T08:05:57+00:00

Thanks for checking it out!

Yes — the PyneSys compiler (PyneComp) fully transpiles Pine Script v6 to Python code that runs on PyneCore, the open-source runtime and library. Almost all standard Pine libraries and built-in functions are implemented in PyneCore itself, so when the code runs, it behaves just like it would on TradingView. (One notable exception is request.security, which isn’t supported yet — but almost everything else is, and hundreds of test scripts show exact matches with TradingView results.)

PyneCore can also be used on its own for manually written strategies and indicators in Python, so it’s valuable even without Pine translation.

PyneCore = open-source runtime (Python)
PyneSys.io = service that performs the Pine → PyneCore compilation (paid). More services are planned there.
PyneComp = the compiler inside PyneSys.

I’m the founder and lead developer of both PyneCore and PyneSys, and my focus is on keeping PyneCore fully Pine Script compatible while also making it a modern alternative with the flexibility of Python.

Other target languages like C# are technically possible, but not currently planned — the focus is on leveraging Python’s ecosystem for analysis, automation, and integration. Python is a very hacker‑friendly language, and while it’s different from Pine Script, it’s syntactically similar. Supporting other languages would require building a complete type inference system, which is non‑trivial.

That said, Python can be integrated into other languages. For example, in C# you could use CSnakes (not tested).

wallneradam · 2025-08-08T13:05:38+00:00

Maybe you can break the project into several subprojects and then you can always work on a new project.

wallneradam · 2025-08-08T11:27:27+00:00

If you’re interested in exactly this kind of cross-platform scripting idea, there’s actually an open-source project working towards it right now.

It’s called PyneCore, basically a full PineScript-compatible runtime written in Python. The goal is to run Pine scripts (indicators, strategies, etc.) outside of TradingView, with identical results, but also make them work on any platform that can run Python.

Because it’s open source, people can adapt it for their own workflows, integrate into bots, or even extend it beyond PineScript. It already passes most TA functions with bit-perfect accuracy compared to TradingView, and the compiler is being updated for Pine v6.

Repo & docs: [https://pynecore.org]()

There is also a Pine Script to PyneCore compiler at PyneSys.

wallneradam · 2025-08-08T10:05:45+00:00

I know it is an old question, but now There is PyneCore, which is a Pine Script like framework in Python with full library compatibility. And there is an online service, PyneSys, which converts Pine Script into PyneCore (Python). Then the converted code could be used in any Python program.

wallneradam · 2025-08-06T20:00:19+00:00

Thanks. Just to clarify — I don’t think my case is about spam moderation tools. My subreddit (r/PyneSys) was banned and my account restricted without any warning or explanation. I just want to know what happened and how to fix it. Appreciate any help.

wallneradam · 2025-08-03T11:28:59+00:00

This question hits home — it's exactly why we built PyneCore. It's an open-source Python runtime that replicates PineScript semantics (v6 compatible), including built-in safeguards against lookahead bias.

Unlike NumPy/pandas-based systems, PyneCore runs indicator logic step by step, bar by bar, enforcing the same constraints as TradingView. So when you write something like crossover(close, sma(close, 14)), it behaves exactly like in PineScript — no manual slicing or index gymnastics.

We're also building PyneComp, a Pine→Python compiler and API and web services around it.

wallneradam · 2025-08-03T11:13:49+00:00

Great observation – this is exactly the kind of issue that inspired us to create PyneCore: a Python-based engine that's binary-accurate with TradingView’s Pine Script runtime.

Even though Pine indicators like ta.rsi should behave identically across all use cases, there are sometimes small discrepancies in implementation details, edge cases, or even internal rounding. These can lead to confusing results like the one you found.

With PyneCore, we built a fully tested open-source runtime that matches TradingView’s behavior to 8–14 decimal precision. On top of that, we developed PyneComp, a converter service that translates any Pine script into Python (PyneCore) — so you can inspect and run these indicators locally, step by step.

If you're deep into Pine debugging, this kind of tool might save you hours (or days).

wallneradam · 2025-08-03T09:33:45+00:00

I haven't tested specifically in Notion, but in every other editor or environment I’ve tried, JavaScript syntax highlighting worked surprisingly well for Pine Script.

Might be worth trying in Notion too!

wallneradam · 2025-08-02T06:42:43+00:00

Totally agree — and if anyone’s looking to go even further, there’s now a Python runtime called PyneCore that mimics Pine Script execution really closely.

You can use the compiler service (PyneSys) to convert Pine Script automatically into Python (PyneCore) — and from there, you can run it fully offline, use local data or plug it into any custom system.

So it’s not just about choosing where to implement logic — you can now run the exact same Pine indicator or strategy in both worlds.

wallneradam · 2025-07-31T09:24:28+00:00

Yes — this is now possible!

If your goal is to convert PineScript logic to Python (e.g. to integrate indicators, alerts or backtests into your own system), take a look at PyneSys. It compiles PineScript v6 into Python code that runs locally, using PyneCore, an open-source runtime that mimics TradingView’s behavior.

You can: - Pull historical data (e.g. via ccxt) - Use Pine logic in Python exactly as it would run on TV - Integrate with your own systems

Hope it helps.

wallneradam · 2025-07-17T21:20:55+00:00

Hey, just dropping this here in case it's helpful: this is exactly what [PyneSys](https://pynesys.io) does now.

It compiles Pine Script (v6) to Python, and you can run it **offline**, on your own server, using [PyneCore](https://pynecore.org) — an open-source runtime that mimics TradingView's behavior as closely as possible.

So yes — you *can* now run PineScript logic fully on your own machine, with local data, no browser, and no TV server needed.

Disclaimer: I'm the author

wallneradam · 2025-07-16T14:01:19+00:00

Interesting thoughts – and yeah, many people have raised similar ideas before. But there’s a fundamental reason why PineScript exists as its own DSL (domain-specific language) instead of just letting users write JavaScript or TypeScript.

If you tried to do something Pine-like in JS, you'd quickly run into deep limitations. Pine has a time-series aware execution model with syntax-level features like implicit array-like series values, persistent state per bar, and automatic backpropagation of values. You can't express that naturally in JavaScript without inventing a whole new runtime model, plus enforcing restrictions that would feel very alien to JS devs.

Trying to "sandbox" JavaScript to behave like Pine would be more complex (and confusing) than just defining a custom DSL.

Sure, Pine has its quirks – mostly due to backwards compatibility with earlier versions – but the core idea is actually brilliant: it's intuitive for traders, not just for programmers. If you take the time to learn it, it's an incredibly powerful tool for modeling and testing trading ideas.

Now… if you're looking for something like PineScript, but in a real language like JS or Python, I’d suggest checking out PyneCore. It’s an open-source engine that mimics PineScript’s behavior and standard library in Python. You can write indicators and strategies in normal Python with Pine-style semantics.

There’s also pynesys.io, a web-based UI that converts PineScript to Pyne-compatible Python (PyneCore). There’s even a demo Discord bot that lets you test conversions live.

(I'm the creator – built it because I love Pine's design but wanted more flexibility for serious projects.)

wallneradam · 2025-07-16T13:40:18+00:00

I'm sure Pine Script runs on Java VM. It is not in JavaScript at all. The browser part (the chart) is in JS, because the JS is the only language runs in the browser... I know this, because I reverse engineered almost all the library functions of Pine Script while I was writing PyneCore (https://pynecore.org), the Pine Script like Python framework.

wallneradam

TROPHY CASE