DEV Community: Khushal Jain

There is no official grammar for Pine Script, so I wrote a small one

Khushal Jain — Mon, 26 Oct 2026 07:17:55 +0000

If you have ever tried to lint, format, or diff TradingView Pine Script programmatically, you have hit the same
wall: there is no official grammar. TradingView does not publish or maintain a tree-sitter grammar or an
ANTLR grammar for Pine Script. Every parser you can find is third-party, and third-party grammars for a
language that changes with each Pine version go stale quietly - they just stop matching real-world code.

I could not find anything to put in a CI pipeline for my indicators, so I wrote
PineSprout (pip install pinesprout, Python 3.12+, Linux/macOS/Windows,
MIT). This post is about the parser decision and the linter rules, which are the two parts worth stealing.

The whole toolkit in one CLI

pinesprout generate "<prompt>"     # Claude-powered, from natural language
pinesprout template new ema-cross-indicator --title "My EMA Cross" -o my_indicator.pine
pinesprout lint my_indicator.pine
pinesprout format my_indicator.pine --write
pinesprout analyze my_indicator.pine
pinesprout optimize my_indicator.pine
pinesprout explain my_indicator.pine
pinesprout upgrade legacy_strategy.pine --to 6 --write
pinesprout docs my_indicator.pine --format markdown -o DOCS.md
pinesprout readme my_indicator.pine -o README.md
pinesprout report my_indicator.pine

Every command supports --json. That is not a nicety - it is the reason the tool is usable outside a terminal.
Machine-readable output means the linter can gate a PR, the formatter can run in a pre-commit hook, and the
upgrader can be scripted across a folder of old v4 scripts.

Why a hand-rolled lexer instead of tree-sitter

Two options existed: depend on an unofficial grammar, or write a small one. I wrote the small one.

pinesprout/core/
├── lexer.py        # regex-based Pine Script tokenizer
├── parser.py       # lightweight AST builder
├── ast_nodes.py    # typed AST node definitions
├── formatter.py    # deterministic code formatter
├── linter.py       # static analysis rule engine
├── analyzer.py     # structural / complexity analysis
├── optimizer.py    # refactor suggestions
├── upgrader.py     # v4 -> v5 -> v6 migrations
└── version_rules.py# deprecated symbols & migration rules

The deliberate constraint: the output shape mirrors a tree-sitter concrete syntax tree - typed nodes,
line/column spans, a children list. Nothing downstream (formatter, linter, analyzer, optimizer, upgrader)
knows or cares how the tree got built.

That buys two things:

It handles real-world Pine's edge cases without waiting on a third party's release cycle.
If TradingView ever ships an official grammar, it drops in behind parser.py and no consumer changes.

A regex tokenizer is not "proper" compiler design, and I am fine with that. It is ~two files, dependency-free,
well tested, and it removes the only thing in the project I could not control.

The lint rule that pays for itself: repaint risk

Pine's most expensive class of bug is not a syntax error, it is an indicator that looks brilliant historically
and lies in real time. Repainting. So the linter has a dedicated category (repaint-risk) driven by an actual
list in version_rules.py:

REPAINT_PRONE_FUNCTIONS = {
    "request.security",
    "security",
    "ta.valuewhen",
    "ta.barssince",
    "input.source",
}

request.security() on a higher timeframe without a lookahead guard, ta.valuewhen() reading a value that has
not settled on the real-time bar - when one of these shows up in a plot path, the linter flags the line and
explains that the script can repaint historical values on lower timeframes, with a separate note for the case
where the repainting is intentional. There is a matching PERFORMANCE_SENSITIVE_FUNCTIONS set (ta.sma,
ta.ema, ta.rsi, ta.atr, ta.stoch, ta.macd, ta.highest, ta.lowest) because calling a rolling
series inside a loop is the second most common way to make a script crawl.

Alongside those, the rule set covers unused variables, deprecated syntax, and general performance issues - the
four things that actually make an indicator script unmaintainable. Because the rules are a rule engine, not a
pile of regexes, you can add your house style without touching the core:

# .pinesprout/plugins/my_rules.py
from pinesprout.plugins.base import PineSproutPlugin, LintRule
from pinesprout.core.linter import LintIssue, Severity, LintCategory

class NoMagicColorsRule(LintRule):
    name = "no-magic-colors"

    def check(self, source: str) -> list[LintIssue]:
        issues = []
        for i, line in enumerate(source.splitlines(), start=1):
            if "color=color.red" in line:
                issues.append(LintIssue(
                    line=i, severity=Severity.INFO,
                    category=LintCategory.STYLE,
                    message="Avoid hard-coded colors; expose as an input.",
                ))
        return issues

class MyPlugin(PineSproutPlugin):
    name = "my-org-rules"
    version = "1.0.0"

    def lint_rules(self):
        return [NoMagicColorsRule()]

PLUGIN = MyPlugin()

Plugins load from a local .pinesprout/plugins/ folder or through a pinesprout.plugins entry point, so a team
can version its own rule pack as a package.

Upgrading v4 → v5 → v6

Pine's version migrations are mostly mechanical renames, and they live as data rather than as if-statements in
the upgrader:

# `study()` was renamed to `indicator()` in Pine v5.
# `security()` moved to the `request.*` namespace in v5.   -> request.security(
# `strategy.performance` -> strategy.closedtrades.* accessors introduced in v6

A regex rewrite table plus typed DeprecatedSymbol entries is honestly enough for a language whose breaking
changes are namespace moves. upgrade --to 6 --write applies them, and it is the command I reach for most,
because a v4 script you still believe in is worth more than a rewrite you will never start.

The Studio, if you prefer a browser

streamlit_app.py wraps the CLI: describe a strategy in plain English (AI-generated), pick a template, or paste
your own script, then lint / format / analyze / optimize / explain / upgrade / document it with one-click
downloads.

The bit that is genuinely fun is the Template Builder: 25 indicators (trend, momentum, volatility, volume) ×
4 signal patterns × 3 risk-management styles, with every length, threshold and stop-loss % adjustable -
thousands of distinct scripts, all of them lint-clean because they come out of the same formatter the CLI uses.
There is also a live scrolling ticker (NIFTY 50, SENSEX, BANK NIFTY, commodities via yfinance) and an NSE-style
index watch plus a TradingView global heatmap for the market-browsing side.

pip install -e ".[dev]"
streamlit run streamlit_app.py

Guardrails worth stating

PineSprout only ever operates on Pine Script source you provide. It does not fetch, decompile, or bypass
protection on TradingView's invite-only or protected scripts. Anyone building tooling in this space should say
that out loud in the README rather than let people assume - it is the difference between a useful tool and a
ToS incident.

Dev loop is pytest, ruff check ., mypy pinesprout, and CI runs on every push.

What's the buggiest pattern in your Pine scripts - repainting on historical bars, or security() look-ahead?
And if you maintain a TradingView repo, do you run any lint/format gate on .pine files today? The toolkit is
85599/pinesprout on PyPI and GitHub, MIT - the parser is the part I would
most like someone to disagree with.

Windows has a free OCR engine. I pointed it at my broker's position grid.

Khushal Jain — Mon, 26 Oct 2026 07:02:16 +0000

Every options trader I know keeps their book in an Excel sheet they update by hand. Strikes, quantities,
premiums, and a row of "what if NIFTY is here at expiry" columns that they retype every time the market moves.
The sheet is the honest part of the process - it is the only place where the size of the risk is written down.
And it is also the part nobody wants to maintain.

So I built a tool around one idea: the screenshot your broker already shows you is the input format.

Drop it in, get back a workbook with live premiums, live P&L, and a scenario grid that recalculates itself.
No broker login, no API key, and the screenshot never leaves the machine.

The repo is nifty-desk (MIT, Python, Windows). This post is about the
two parts that were actually hard: reading the screenshot, and getting the numbers to stay live.

The trick nobody tells you about Windows OCR

Windows ships an OCR engine - Windows.Media.Ocr, the same one the Photos app uses. It is free, it runs
locally, it has recognizers per language, and it needs no install. The catch is that it is a WinRT API, so
the practical way to reach it from Python is to shell out to PowerShell.

Here is the real call from ocr/winocr.ps1:

Add-Type -AssemblyName System.Runtime.WindowsRuntime
Add-Type -AssemblyName System.Drawing

[Windows.Media.Ocr.OcrEngine,Windows.Foundation.UniversalApiContract,ContentType=WindowsRuntime] | Out-Null
[Windows.Graphics.Imaging.BitmapDecoder,Windows.Foundation.UniversalApiContract,ContentType=WindowsRuntime] | Out-Null

$engine = $null
$langs = @([Windows.Media.Ocr.OcrEngine]::AvailableRecognizerLanguages)
$pick = $langs | Where-Object { $_.LanguageTag -eq $LanguageTag } | Select-Object -First 1
if ($null -eq $pick -and $langs.Count -gt 0) { $pick = $langs[0] }
if ($null -ne $pick) { $engine = [Windows.Media.Ocr.OcrEngine]::TryCreateFromLanguage($pick) }

AsTask + a small Await helper turns the WinRT async calls into something a script can wait on - that is
the only way to drive WinRT from Windows PowerShell without writing a compiled app.

Upscale before you recognise. This was the single biggest accuracy win. The ODIN terminal draws its
position grid in a roughly 9px font. At 1:1 the engine silently drops characters, and a dropped character in
a strike price is not a typo - it is a different trade. So the image goes through a high-quality bicubic
resize at 2x first:

if ($Scale -ne 1.0) {
  $src = [System.Drawing.Image]::FromFile($Path)
  $dst = New-Object System.Drawing.Bitmap ([int]($src.Width * $Scale)), ([int]($src.Height * $Scale))
  $g = [System.Drawing.Graphics]::FromImage($dst)
  $g.InterpolationMode = [System.Drawing.Drawing2D.InterpolationMode]::HighQualityBicubic
  $g.DrawImage($src, 0, 0, $dst.Width, $dst.Height)
}

Twenty-two lines of PowerShell replaced what would otherwise be a cloud OCR bill and a privacy problem.

Parsing: read the header, never the column position

A grid is not a text file. My first instinct was to split each row on whitespace and index into it, which
works exactly once, on my screen, on my broker layout.

The version that ships reads the header row and only uses the columns that header actually spells out.
If a broker hides three columns, Net Qty, Market Price and MTM still land in the right cells, and nothing is
guessed at. Two other things earned their complexity:

CE/PE recovery. When OCR loses the option type on a leg, recover it from the sibling leg of the same strike, or from the live NSE price for that instrument. Do not fail the whole row for one dropped glyph.
Lot size auto-detection. Quantities in the grid are in lots; the workbook needs contracts. The tool infers the lot size from the quantity values instead of asking you to type it.

Then there is the sign convention, which is the part that quietly ruins P&L sheets:

The terminal shows a short as a negative Net Qty. The workbook writes a SELL as a positive Qty with a
Side column, and the scenario grid reads sell-positive / buy-negative so the formulas come out right.

That convention is stated in the README and printed in the sheet, because the alternative is a book that looks
correct and is wrong by twice the position.

Keeping it honest: live prices, not a snapshot

A parsed screenshot goes stale in about four minutes. So each workbook pulls premiums and spot from the public
NSE option chain - no key, no subscription - and refreshes every 5 minutes.

The output is one block per expiry, laid out like the sheet a person would have made by hand:

a full STRIKE / QTY / PREMIUM ladder at a 50-point gap, including the zero rows, so you can type an unstated position straight into the sheet
CP IF <spot> scenario columns at a 100-point gap, each one a live IF formula - edit a quantity or a rate and the whole grid recalculates
CE section, PE section, and a NIFTY futures line that is always present even when the screenshot has no future, so you can add one yourself
a grand TOTAL, with each expiry printing on its own page

This is real generated output, not a mockup:

The line I care about most is the CP IF grid. It answers "what happens to my book if the market sits exactly
where it is - or moves 500 points against me" before the market answers it for you.

Shipping a .exe to people who do not have Python

The traders who wanted this are the least likely to run pip install. So there is a Windows binary built with
PyInstaller (build_exe.bat in the repo does it in one command if you would rather build it yourself).

Two things I got pushed on, and handled deliberately:

"Windows protected your PC." That is SmartScreen, because the exe is unsigned - code-signing certificates
cost money. The README says exactly that, tells you to build from source if you prefer, and the whole source is
right there. I would rather explain the warning than pay for a certificate I cannot honestly make mean more
than it does.

"It read 0 rows." Silent failure is the worst outcome for a parsing tool, so the activity log now names the
cause:

"none of them formed the ODIN position grid" - header row was cropped out of the screenshot
"does not follow the standard ODIN column layout" - columns rearranged or hidden in that terminal
"no text at all" - the English OCR recognizer is not installed (Settings → Time & Language → Language)
"every row was filtered out" - grid parsed fine, untick NIFTY rows only or Hide fully closed

Each message maps to an action. Debugging became a checkbox instead of a support conversation.

Run it

No-Python path: grab NiftyDesk-win64-v1.0.4.zip from the
latest release, unzip, double-click NiftyDesk.exe.
Workbooks land in an output folder next to it.

From source:

pip install -r requirements.txt
python server.py     # http://127.0.0.1:8765/

Privacy note, stated in the code's shape rather than a policy page: the only network request the tool makes is
the public NSE quote call. Positions and screenshots stay local. And it is a risk-visibility and bookkeeping
tool - it places no orders, promises no returns, and is not investment advice.

What I would do differently

Wire the same pipeline to the other popular terminals' layouts (right now it is built around ODIN's grid), and
push the scenario grid to options other than NIFTY, since the parsing is symbol-agnostic but the defaults are not.

Which broker's position grid do you fight with every week - and what does your Excel sheet refuse to tell you
about your own risk? If you want the workbook itself, the repo is
85599/nifty-desk. It is MIT, so fork it, break it, or hand me a
screenshot layout it chokes on.

No API key, no data vendor: pulling live NSE + BSE option chains in Python

Khushal Jain — Mon, 26 Oct 2026 07:00:55 +0000

Retail option analytics in India has a data problem. Licensed feeds cost real money, brokers gate their API
behind accounts, and the free tools that exist hand you a wall of numbers and stop there. Meanwhile the
exchanges publish option chains on their own public websites - which anyone can read, and which nobody will
support you when it changes.

I built Strike & Hedge on exactly those public endpoints: live
NSE and BSE chains, Black-Scholes Greeks solved locally, PCR, max pain, OI walls, expected move, and a
rule-based trade plan. No API key. MIT. 45 offline tests.

This post is the field notes - the parts that are not in any tutorial because they only show up when a
government exchange quietly retires an endpoint on a Tuesday.

The anti-bot wall comes first

Both exchanges sit behind Akamai. Plain requests gets 403s, and no amount of header cosplay fixes it,
because the TLS handshake itself is the fingerprint. What works:

# copilot/nse.py, copilot/bse.py
# curl_cffi impersonates a real Chrome TLS/JA3 profile; warm cookies from the homepage first
from curl_cffi import requests as session   # falls back to `requests` if curl_cffi is unavailable

Keep the fallback. curl_cffi is a compiled dependency and it will not install on some machine you care
about; the tool should degrade to "this source did not load" rather than "this tool does not start".

Endpoints are a moving target, so write down what moved

The specific things that bit me, as of October 2026:

Need	What is actually there
NSE chains	`option-chain-v3` + `option-chain-contract-info`. The old `option-chain-indices` endpoint is retired
BSE (SENSEX) chain	`DerivOptionChain`, which wants the expiry formatted as `15 Oct 2026`
BSE expiry list	not published. Upcoming Thursdays get probed until one answers
NSE futures quotes	gone. `quote-derivative`, `quote-v2` and `last-price-v5` all 404
FINNIFTY daily history	niftyindices.com - Yahoo delisted `^CNXFINANCE`, and NSE's own chart API returns empty for every index
FINNIFTY intraday	no public source exists

Two of those are lies rather than gaps, and they are the dangerous kind:

BSE reports Absolute_Change_OI as 0 intraday. Not "flat" - not published yet. Rendered as a real number, it tells you writers are not active when the exchange simply has not said.
BSE sends no IV. So IV gets solved from the premium. And when a deep-ITM quote will not solve, the row shows —. A solver forced to always answer will happily hand you a 500% IV, and the Greeks downstream will believe it.

When a number cannot be had, derive it and label it

With NSE's futures quote endpoints retired, a futures card has no honest price. The tool derives the futures
level from put-call parity on the ATM strike - from copilot/chain.py:

def synthetic_futures(chain, r=0.065):
    """Futures level implied by put-call parity on the ATM strike: F = K·e^(-rT) + CE - PE."""
    ltp = k * math.exp(-r * t) + c - p
    ...
    "source": "put-call parity on ATM strike",

Then three things matter more than the formula:

the card is labelled as derived, and says it can be tens of points off your broker's price
the parity basis is never scored as a signal - last-traded option quotes put that much noise into it
there is no futures OI or buildup anywhere in the score, because that data does not exist

Same principle for the FINNIFTY intraday panel: it falls back to recent daily bars and says that it did.
Silent fallback is where dashboards go to die. A tool that narrates its own blind spots gets used; one that
hides them gets believed, and then gets abandoned.

And at the close: signals come from a chain snapshot, not tick data, so near 15:30 IST the settled expiry is
dropped. Otherwise you get a ₹0.05 premium with nonsense Greeks, printed as if it were actionable.

Split the deterministic engine from the LLM

The pipeline is deliberately two halves:

 NSE option-chain-v3 ─┐
 BSE DerivOptionChain ─┤→ chain.py    normalise + Black-Scholes Greeks / IV
 niftyindices.com ─────┤      ↓
 Yahoo quotes/VIX ─────┘  analytics.py   PCR · max pain · OI walls · expected move
                               ↓
                          signals.py     bias + entry / stop / target / exit / lots
                               ↓
                    dataflows.py → agents.py → graph.py    (optional AI desk)
                               ↓
                          reporting.py   markdown report + decision log

signals.py needs no key at all and produces BULLISH / BEARISH / RANGE / AVOID with a score and
written reasons, plus a concrete plan: instrument, entry, stop, target, R:R, lots, max loss in ₹, exit rule.
Stops and targets come from ATR and OI walls on the underlying, converted to premium through delta - so
they react to real price geometry instead of a fixed percentage. Never naked selling: bullish → BUY CE beyond
ATM (plus a futures long on the derived level), range → defined-risk credit spreads, sell near the OI wall,
hedge two strikes further out.

The risk model has one behaviour I am stubborn about:

Type in capital and risk % - if one lot already risks more than your capital × risk %, the tool refuses
to round up. It tells you the position does not fit, instead of quietly showing "1 lot".

The AI desk (chain / volatility / flow / news analysts → bull vs bear debate → risk → portfolio manager) sits
on top of the same numbers, across 8 backends: Anthropic, OpenAI, Gemini, DeepSeek, Groq, OpenRouter,
Ollama (fully local, no key), or any OpenAI-compatible endpoint. Two guards make it behave:

Grounding check. The LLM is given the rule engine's numbers. If its quoted entry is far from the live premium - the classic mistake of stating a strike as a premium - the rule-engine level is shown instead, with a warning.
Decision log. Every AI call is scored later against the underlying's actual move with a hit/miss flag, and those lessons feed into later runs. An agent loop with no outcome tracking is a random number generator with good grammar.

Here is the engineering ask buried in that design: keep the rule engine separate. If you only want chains,
Greeks and signals, delete agents.py and graph.py entirely and the rest still works.

Make failure debuggable, and make tests offline

When a chain will not load, the answer is one request away:

curl http://localhost:8000/api/diag/NIFTY     # what each price source actually returned

Endpoints change and rate limits bite without notice, so a debug endpoint that shows raw per-source responses
turns "it's broken" into "NSE is 403ing and BSE is fine".

The test suite is offline on purpose - 45 tests, no network, no keys, so CI stays green whether or not an
exchange is having a day:

python -m pytest tests -q
python tests/ui_harness.py    # full UI on synthetic data → http://127.0.0.1:8765

That synthetic harness is the other half of the trick: it lets a reviewer see the entire UI without a broker
account, a key, or market hours. No frontend build step either - web/ is plain HTML/CSS/JS served by FastAPI.

git clone https://github.com/85599/Strike-and-Hedge.git
cd Strike-and-Hedge && pip install -r requirements.txt
uvicorn server:app --port 8000     # open http://localhost:8000

The part you should read before you scrape

This is a scraper, not a licensed feed. It reads public endpoints at request time and caches briefly; it is
not a redistribution right, and exchanges can change terms whenever they like. Lot sizes in the repo are
fallbacks - SEBI revises them, so verify with your broker. And publishing buy/sell calls publicly can
require SEBI Research Analyst registration, which is worth knowing before you share output anywhere. It is an
educational research tool, not investment advice, and not issued by a registered research analyst.

Which Indian exchange endpoint has wasted the most of your afternoon - and is anyone tracking a working
futures-quote source now that NSE's are 404ing? If you want the whole pipeline to read or break:
85599/Strike-and-Hedge. PRs for endpoint changes, lot sizes and
strike steps are the ones I merge fastest.