Why Industrial Engineers Are Learning Python (And Why Jython Isn't Enough)

Table of contents

• The AI assistant experiment
• Why Python became essential for industrial automation
• The Jython trap, learning a deprecated language
• What Ignition actually uses: Jython 2.7
• The AI era widened the gap
• The compounding disadvantage
• Real productivity comparison
• What about other industrial programming languages?
• OPC Data Wrangler: real Python for industrial transforms

---

The AI assistant experiment

Try this. Open GitHub Copilot, ChatGPT, or Claude. In a Python 3 file, type the comment # Calculate 10-sample moving average for sensor data. Watch what happens.

In Python 3.x you get something like this:

import pandas as pd

def moving_average(data, window=10):
    return pd.Series(data).rolling(window=window).mean()

Professional. Works immediately.

Now try the same thing in Ignition SCADA's Jython environment. The AI suggests the exact same code. When you run it:

ImportError: No module named pandas

You Google "Jython moving average." You find Python 3 tutorials that do not work. You spend 30 minutes writing it manually from scratch.

That is the hidden cost of using a deprecated language in 2025.

This post walks through why industrial engineers are learning Python, why many are accidentally learning the wrong version, and how the AI revolution widened this gap by an order of magnitude in the last two years.

---

Why Python became essential for industrial automation

Python's growth in industrial automation is not a fad. Real shifts in how manufacturing works are driving it.

AI and machine learning in manufacturing

According to the JetBrains State of Python 2025 survey, 41% of Python developers use it specifically for machine learning.¹ In manufacturing, this shows up as predictive maintenance (predicting equipment failures before they happen), AI-powered defect detection in quality control, machine learning models for process optimization, and self-adjusting control loops in autonomous systems.

These are not future possibilities. They are happening now. They all require Python's ML ecosystem (NumPy, Pandas, scikit-learn, TensorFlow).

Industrial IoT data

A modern production line might have 100+ sensors reporting every second, quality metrics from vision systems, energy consumption data, maintenance logs, and production schedules. 51% of Python developers work on data exploration and processing.² Pandas, Matplotlib, and NumPy make sense of the flood.

Cost reduction through automation

Industry reports show Python automation has helped companies reduce operational costs by about 30%.³ In manufacturing this looks like automated data collection replacing manual logging, scripted quality checks, batch processing for repetitive tasks, and integration scripts that connect disparate systems.

Industry standard skills

Python overtook JavaScript as the number-one language on GitHub in 2024,⁴ with a 22.5% year-over-year increase in contributions driven by AI adoption.⁵

For hiring managers this matters. New engineering graduates know Python, not proprietary scripting languages. Data scientists speak Python. Systems integrators are adding Python capabilities. Open-source automation tools use Python.

Python is no longer optional for modern automation engineering. It is foundational.

---

The Jython trap, learning a deprecated language

This is where it gets complicated.

57-65% of Fortune 100 companies use Ignition SCADA from Inductive Automation.⁶ Ignition is a strong SCADA platform. It is powerful, widely adopted, and enterprise-trusted. It also popularized "Python" scripting in industrial automation.

But Ignition does not use Python. It uses Jython.

Jython is Python implemented on the Java Virtual Machine.⁷ The choice was reasonable when it was made. It let Ignition leverage Java's industrial ecosystem, integrate with Java-based SCADA systems, expose Python syntax to engineers, and access Java libraries directly. Java dominated enterprise software at the time.

The problem is that Python 2.7 officially ended support on January 1, 2020.⁸ That was nearly six years ago. The most recent Jython release is 2.7.4 (August 2024).⁹ No official Jython 3.x version exists,¹⁰ despite years of "coming soon" promises.

Engineers learning "Python" in Ignition are learning a deprecated language. When they Google "Python tutorial," they find Python 3.x resources. When they apply those tutorials in Ignition, things break: syntax errors (Python 3's print() function vs Python 2's print statement), missing features (no f-strings, no type hints, no async/await), import failures (libraries expect Python 3).

---

What Ignition actually uses: Jython 2.7

From Inductive Automation's documentation:¹¹

C libraries aren't accessible. Libraries written in pure Python are generally available in Jython. Since the majority of the most popular Python libraries do require C libraries, the selection of Python libraries that can be used in Ignition directly is fairly limited.

In plain English: most of the Python libraries that matter for automation do not work in Jython.

Blocked libraries include NumPy (numerical computing), Pandas (data manipulation), SciPy (scientific computing), Matplotlib (visualization), scikit-learn (machine learning), TensorFlow and PyTorch (deep learning), requests (HTTP, has C dependencies), asyncua (modern OPC UA client), and pyModbus (Modbus protocol library).

What works in Jython: pure Python libraries (very few of them), Java libraries via Jython's Java integration, and Ignition's built-in functions.

The workaround culture

Engineers are resourceful. They have developed workarounds.¹² Build a Flask or Bottle API in real Python 3, have Ignition call HTTP endpoints, process data externally and return results. Or use system.util.execute() to run external Python 3 scripts and pass data via command line or files. Or implement NumPy algorithms by hand: 10x more code, 10x more bugs, reinventing well-tested wheels.

From an Inductive Automation forum discussion about Python 2.7 limitations, Kevin Herron of Inductive Automation wrote:¹³

We don't see the evolution and divergence of Python as a huge issue. The scripting language doesn't need to evolve at the same pace.

The disconnect between vendor perspective and engineer needs explains why so many engineers are frustrated.

---

The AI era widened the gap

Before 2022, the Jython limitation was annoying but manageable. You couldn't use NumPy, so you wrote algorithms manually. It took longer, but you got the job done.

Then GitHub Copilot, ChatGPT, and Claude arrived.

Python engineers got AI pair programmers writing code alongside them. Productivity rose sharply. The catch: the productivity boost is highly language-dependent.

How AI code assistants work

Large language models like GPT-4, Claude, and Copilot's Codex are trained on publicly available code: 60 million Stack Overflow posts,¹⁴ 2.7 terabytes of source code across 350+ programming languages,¹⁵ and GitHub's public repository history. The data is heavily skewed toward popular languages.

Python's dominance in AI training data

Python's presence: number one on Stack Overflow, the most-discussed language; overtook JavaScript on GitHub in 2024¹⁶ driven by AI adoption; dominates The Stack dataset alongside Java and JavaScript.

Jython 2.7's presence: minimal on Stack Overflow (mostly 2010-2015 questions), tiny fraction of GitHub, essentially zero dedicated Jython code in major training datasets.

A 2024 academic survey of 111 research papers on LLM code generation found:¹⁷

The performance disparity is starkly illustrated by the results of the MultiPL-E benchmark, with significantly higher scores for Python compared to LRPLs [Low-Resource Programming Languages] for most LLMs.

While generation for general-purpose languages like C, C++, and Python has improved significantly, LLMs struggle with custom function names in Domain Specific Languages or DSLs, which leads to higher hallucination rates and syntax errors.

LRPLs and DSLs face unique challenges, including severe data scarcity and, for DSLs, highly specialized syntax and semantics that are poorly represented in general-purpose datasets.

AI assistants work for Python 3.x. They struggle with Jython. They fail with proprietary industrial DSLs.

---

The compounding disadvantage

Three workflows side by side.

Python 3.x with AI

Type a comment describing what you need. Copilot suggests complete, correct code. Review and accept. Run it; it works. Intelligent autocomplete trained on billions of lines of Python. ChatGPT and Claude write complex functions. Stack Overflow answers copy-paste perfectly. Error messages map to instant Stack Overflow solutions. AI refactors and optimizes.

Estimated productivity multiplier: 2 to 5x vs manual coding.¹⁸

Jython 2.7 with "AI assistance"

Type a comment. Copilot suggests Python 3 code with NumPy or Pandas. Try to run; ImportError. Google "Jython moving average." Find Python 3 solutions that do not work. Find Python 2 solutions that maybe work but are outdated. Eventually write it manually. Debug for another 20 minutes.

Stack Overflow answers use Python 3, mostly incompatible. AI suggests NumPy and Pandas, not available. Error messages map to Python 3 solutions that do not apply. AI refactors using features the runtime does not have.

Estimated productivity multiplier: 0.5 to 1.5x. AI creates confusion and wasted time.

Proprietary DSL with "AI assistance"

Type a comment in a proprietary SCADA scripting language. AI has no idea what the syntax is. AI suggests JavaScript-like code that does not work. Manually search vendor documentation (often a 500-page PDF). Find an example, adapt manually. No Stack Overflow, no community help.

Copilot has zero training data; suggestions are random. ChatGPT and Claude hallucinate. AI actively misleads.

Estimated productivity multiplier: 0.2 to 0.8x. AI makes things worse.

---

Real productivity comparison

Task: calculate a 10-sample moving average for vibration sensor data.

Python 3.x engineer (30 seconds):

import numpy as np

window = np.array([])

def transform(value):
    """Smooth vibration sensor with 10-sample moving average."""
    global window
    window = np.append(window, value)
    if len(window) > 10:
        window = window[-10:]
    return float(np.mean(window))

Copilot wrote this. Uses NumPy. Works. Move on.

Jython 2.7 engineer (25 minutes):

First attempt from Copilot:

import pandas as pd  # ImportError

Manual implementation:

def moving_average(data, window=10):
    """Manual implementation since Pandas does not exist."""
    result = []
    for i in range(len(data)):
        if i < window - 1:
            result.append(None)
        else:
            window_data = data[i-window+1:i+1]
            avg = sum(window_data) / float(window)
            result.append(avg)
    return result

Manually tested. Off-by-one error found. Fixed. Works.

Time ratio: roughly 50x slower.

Proprietary DSL engineer (2 hours):

AI suggests JavaScript code. Doesn't match DSL syntax. Search vendor docs. Find cryptic example. Adapt manually. Debug vendor-specific quirks. Eventually works.

Time ratio: roughly 240x slower.

---

What about other industrial programming languages?

What about IEC 61131-3 languages used in PLCs (Ladder Diagram, Structured Text)?

Recent academic research from October 2024 tested LLM support for industrial automation languages.¹⁹

Structured Text: "LLM4PLC introduced syntax checkers... proving highly suitable for industrial automation applications." With fine-tuning, LLMs can generate ST. It requires specialized training.

Ladder Diagrams: "Generating Ladder Diagrams (LD) automatically remains a challenge even for very simple use cases."

Sequential Function Charts: "It is possible to generate correct SFC for simple requirements when LLMs are provided with several examples."

The pattern: industrial languages get basic LLM support if you use vendor-specific fine-tuning (Siemens Industrial Copilot for TIA Portal,²⁰ for example), if you accept being locked into specific platforms, and if you accept that it is still well behind Python's native LLM support.

---

OPC Data Wrangler: real Python for industrial transforms

This is why we built OPC Data Wrangler.

Embedded CPython 3.12

OPC Data Wrangler embeds CPython 3.12 directly. The core platform is written in Zig for performance. Custom Python scripts run in sandboxed CPython environments.

NumPy works. Pandas works. scikit-learn works. All of PyPI works (500,000+ packages). Real CPython, not Jython, not a limited subset. Zig core for native performance. Sandboxed Python execution for safety.

Because it is real Python, GitHub Copilot suggestions work immediately. ChatGPT and Claude code runs without modification. Stack Overflow answers copy-paste. Modern tutorials apply directly.

Example: moving average the right way

In OPC Data Wrangler's Python Transform node:

import numpy as np

window = np.array([])

def transform(value):
    """Smooth vibration sensor with 10-sample moving average."""
    global window
    window = np.append(window, value)
    if len(window) > 10:
        window = window[-10:]
    return float(np.mean(window))

Transform functions receive a single data point at a time and maintain their own state. Copilot wrote this. It works. No workarounds, no REST APIs, no external scripts. Python with NumPy.

Focused on ETL

OPC Data Wrangler is not trying to be a SCADA platform. It is a narrow, modular tool focused on OPC ETL and data transformation. You get a visual DAG builder with drag-and-drop nodes for common transforms, Python Transform nodes running real CPython 3.12 when you need custom logic, and standard Python modules that travel between projects.

---

The future-proof choice

As LLMs improve, the productivity advantage of Python compounds. More Python code on GitHub, better AI training data, better suggestions, more engineers choose Python, cycle repeats. Jython 2.7 and proprietary DSLs do not get new training data. The gap widens every month.

Python is the language of AI, data science, and modern automation. Jython 2.7 has been deprecated since 2020. The choice for new automation engineers is to learn the language with industry momentum or one that fell behind five years ago.

---

Conclusion

Python became essential for AI/ML, IIoT data processing, and cost reduction through automation. About 70% of businesses use Python for key applications.²¹

But 57-65% of Fortune 100 companies use Ignition, which runs Jython 2.7. That version cannot use NumPy, Pandas, or modern ML libraries. It gets poor AI assistance because the suggestions are for a different language. The skills do not transfer to the broader Python ecosystem.

The AI era turned a library limitation into a productivity gap of 2x to 50x.

OPC Data Wrangler embeds CPython 3.12. Full PyPI ecosystem. AI assistance that works. Industry-standard skills. No workarounds. Zig-based core for native performance. Sandboxed Python execution for safety.

---

Get started

Try OPC Data Wrangler. Register for early access. Read the documentation.

Questions? Reach out on LinkedIn or GitHub.

---

References

Footnotes

1. JetBrains State of Python 2025 Survey, https://blog.jetbrains.com/pycharm/2025/08/the-state-of-python-2025/ ↩

2. Clarion Tech, Python Trends in AI and Automation for Industry, https://www.clariontech.com/blog/python-trends-ai-automation-industry ↩

3. Clarion Tech, Why Bet on Python in 2025, https://www.clariontech.com/blog/why-every-business-leader-should-bet-on-python-in-2025-ai-automation-game-changing-use-cases ↩

4. GitHub Octoverse 2024, https://github.blog/news-insights/octoverse/octoverse-2024/ ↩

5. Stack Overflow Developer Survey 2025, https://survey.stackoverflow.co/2025/technology ↩

6. Enlyft Market Intelligence, Inductive Automation Ignition, https://enlyft.com/tech/products/inductive-automation-ignition ↩

7. Vertech Blog, Tips for Using Python in Ignition SCADA, https://www.vertech.com/blog/tips-for-using-python-in-ignition-scada ↩

8. Python.org, Python 2.7 End of Life, https://www.python.org/doc/sunset-python-2/ ↩

9. Stack Overflow, When Will Jython Support Python 3?, https://stackoverflow.com/questions/2351008/when-will-jython-support-python-3 ↩

10. Jython Project, https://www.jython.org/jython-3-mvp.html ↩

11. Inductive Automation, Python In Ignition, https://support.inductiveautomation.com/hc/en-us/articles/360056397252-Python-In-Ignition ↩

12. Inductive Automation Forum, Python/Jython/CPython Primer, https://forum.inductiveautomation.com/t/python-jython-cpython-libraries-pip-and-python-2-7-vs-3-a-quick-primer/43201 ↩

13. Kevin Herron, Inductive Automation Forum Discussion ↩

14. LLM Training Datasets Research, Stack Overflow Posts Dataset ↩

15. The Stack Dataset v1.2, https://huggingface.co/blog/starcoder ↩

16. GitHub Octoverse 2024 Report ↩

17. Academic Survey on LLM Code Generation, https://arxiv.org/abs/2410.03981 ↩

18. Industry estimates for GitHub Copilot productivity gains ↩

19. Exploring LLM Support for IEC 61131-3, https://arxiv.org/html/2410.15200v1 ↩

20. Siemens Industrial Copilot, https://blogs.sw.siemens.com/thought-leadership/going-beyond-automation-with-the-industrial-copilot-part-2-transcript/ ↩

21. Clarion Tech, Python Business Applications 2025 ↩