Pine-to-Python Translator: 84 Errors Down to 5

DEV Community

84 Errors Became 5: The Version-to-Version Table for a Pine-to-Python Translator

84 Errors Became 5: The Version-to-Version Table for a Pine-to-Python Translator TL;DR: A translator that went from 84 failed scripts to 5 did not get 16 times better in one fix. It got better in three recorded stages — 84 → 13 → 7 → 5 — across nine compile checkpoints and eight run checkpoints, with a per-script diff after every batch proving nothing that used to pass started failing. The headline number, 99.7% in our testing, is the least interesting part. The table is the evidence — and the table includes the one number that got worse, and the one sweep that lied. This is the ninth post in a series where I convert Pine strategies to Python line by line. The last post was about a single fix — the when= desugar — measured trade for trade. This one steps back to the sweep that produced all those fixes, because a single percentage hides the only question that matters: did it get better, version by version, without anything silently getting worse? The short version Compile: 1,827 of 1,911 scripts compiled on 2026-10-21 (95.6%), with 84 analyze failures. By the v45 baseline on 2026-10-24: 1,904 of 1,909 (99.7%), with 5 failures. Run: clean runs went from 1,859 to 1,887 of 1,904 (99.1%), and run errors fell from 45 files to 17 — 9 unique scripts in 7 families. The three stages: 84 → 13 (the big construct families) → 7 (three two-file fixes) → 5 (one overload fix). The last three fixes were two files each. The number that got worse: diagnostics rose from 41 to 55 while failures fell. That is not a regression — it is the price of compiling more scripts, and the post explains why. Zero regressions is a measured claim, not a boast: after every batch, a per-script diff (ok → error must be 0) ran before anything was committed. The totals never moved without the diff agreeing. The sweep that lied: one full sweep reported ran_ok 1,428 — invalid data, deleted, baseline reset. The table below is what survived the rule that caught it. The compile table: nine checkpoints, one direction Each row is a recorded checkpoint from the project log. The "what changed" column is the batch that moved the number; the delta is the sweep total, not a promise about the next batch. Checkpoint Compiled Failures What changed 2026-10-21 evening baseline 1,827 / 1,911 84 Starting point: 95.6% security batch 1,850 / 1,911 61 request.security() tuple literals (17 files) and scalar expressions (8) for-in batch 1,858 / 1,911 53 Iterator typing for for...in (8) namespace batch 1,874 / 1,911 37 Namespace field access (16) + UDT method calls continuation batch 1,890 / 1,911 21 Line-continuation and indentation parsing (8) chart.point batch 1,894 / 1,911 17 chart.point field reassignment table.cell batch 1,896 / 1,911 15 table.cell_set_text_formatting batch 2 (§16.7) 1,902 / 1,909 7 Tuple-switch tail returns, drawing kwargs, chained receivers (2 files each) batch 2b (§16.8) 1,904 / 1,909 5 int[]/float[] overload dispatch on 012_volume-profile-maps (2 files) Three things to notice before the numbers do any persuading: First, the denominator moved. The corpus went from 1,911 files to 1,909 because two illegal inputs were quarantined out of the corpus entirely (M4). Those two were never "fixed" — they were removed from what counts. So the failure count fell by 79, and that 79 is exactly 77 scripts newly compiling plus 2 files removed from the corpus. If you only read the percentage, 95.6% → 99.7%, you miss the two files that left through the side door. They are in the log; they are not hidden. Second, the fix ledger and the checkpoints disagree by two files — and the post says so. The per-construct fix log lists twelve groups totalling 81 files — 17 + 16 + 12 + 8 + 8 + 8 + 2 + 2 + 2 + 2 + 2 across eleven fix groups, plus the 2 quarantined inputs — against a net failure drop of 79. The two-file gap is the difference between counting fixes and counting files: the ledger counts per construct, so a file touched by two fixes counts twice, and the corpus holds duplicate copi...

Powered by Readybot.io