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

Chris Laponsie
10 min read
OPC UAETLTutorialIndustry 4.0

Table of Contents


The AI Assistant Experiment

Let's try an experiment:

  1. Open GitHub Copilot (or ChatGPT, or Claude)
  2. In a Python 3 file, type: # Calculate 10-sample moving average for sensor data
  3. Watch what happens

If you're using real Python 3.x, you'll see something like this:

import pandas as pd

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

Perfect. Professional. Works immediately.

Now try the same thing in Ignition SCADA's Jython environment:

The AI will suggest the exact same code. But when you run it:

ImportError: No module named pandas

You Google "Jython moving average." You find Python 3 tutorials (they don't work). You spend 30 minutes writing it manually from scratch.

That's the hidden cost of using obsolete languages in 2025.

In this article, I'll walk you through why industrial engineers are learning Python, why many are accidentally learning the wrong version, and how the AI revolution has made this gap 10x worse than it was just two years ago.


Why Python Became Essential for Industrial Automation

Python's explosion in industrial automation isn't a fad. It's driven by real, fundamental shifts in how manufacturing works:

1. AI and Machine Learning in Manufacturing

According to industry research, 41% of Python developers now use it specifically for machine learning.1 In manufacturing, this translates to:

  • Predictive maintenance: Predict equipment failures before they happen
  • Quality control: AI-powered defect detection
  • Process optimization: Machine learning models that improve production efficiency
  • Autonomous systems: Self-adjusting control loops

These aren't future possibilities. They're happening right now. And they all require Python's ML ecosystem: NumPy, Pandas, scikit-learn, TensorFlow.

2. Industrial IoT Data Explosion

Modern factories generate massive datasets. A single production line might have:

  • 100+ sensors reporting every second
  • Quality metrics from vision systems
  • Energy consumption data
  • Maintenance logs
  • Production schedules

51% of Python developers work on data exploration and processing.2 Python's data libraries (Pandas for manipulation, Matplotlib for visualization, NumPy for computation) make sense of this flood.

3. Cost Reduction Through Automation

Industry reports show Python automation has helped companies reduce operational costs by 30%.3 In manufacturing:

  • Automated data collection replaces manual logging
  • Scripted quality checks catch issues faster
  • Batch processing handles repetitive tasks
  • Integration scripts connect disparate systems

4. Industry Standard Skills

Python overtook JavaScript as the #1 programming language on GitHub in 2024,4 with a 22.5% year-over-year increase in contributions, driven primarily by AI adoption.5

For hiring managers, this matters:

  • New engineering graduates know Python (not proprietary languages)
  • Data scientists speak Python
  • System integrators are adding Python capabilities
  • Open-source automation tools use Python

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


The Jython Trap: Learning a Zombie Language

Here's where things get complicated.

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

But there's a catch.

Ignition doesn't use Python. It uses Jython.

What is Jython?

Jython is Python implemented on the Java Virtual Machine (JVM).7 Back in the day, this was actually a clever choice. It allowed Ignition to:

  • Leverage Java's mature industrial ecosystem
  • Integrate with Java-based SCADA systems
  • Provide Python syntax to engineers
  • Access Java libraries directly

Historically, this made a lot of sense. Java dominated enterprise software, and running Python on the JVM seemed like the best of both worlds.

The Problem: Jython is Stuck on Python 2.7

Python 2.7 officially ended support on January 1, 2020.8 That was nearly six years ago.

The most recent Jython release is version 2.7.4 (August 2024).9 There is no official Jython 3.x version,10 and there hasn't been one despite years of "coming soon" promises.

This means engineers learning "Python" in Ignition are learning a deprecated language.

When they Google "Python tutorial," they find Python 3.x resources. When they try to 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

Let's get specific about what Jython can't do.

The C Extension Problem

From Inductive Automation's official documentation:11

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: You can't use most of the Python libraries that actually matter for automation.

Blocked Libraries:

  • NumPy - Numerical computing, array operations
  • Pandas - Data manipulation, time-series analysis
  • SciPy - Scientific computing, signal processing
  • Matplotlib - Data visualization
  • scikit-learn - Machine learning (all of it)
  • TensorFlow/PyTorch - Deep learning
  • requests - HTTP library (has C dependencies)
  • asyncua - Modern OPC UA client
  • pyModbus - Modbus protocol library

What works:

  • ✅ Pure Python libraries (very few)
  • ✅ Java libraries (via Jython's Java integration)
  • ✅ Ignition's built-in functions

The Workaround Culture

Look, engineers are resourceful. They've developed some creative workarounds:12

1. External Python 3 via REST API:

  • Build Flask/Bottle API with real Python 3
  • Ignition calls HTTP endpoints
  • Process data externally, return results

2. system.util.execute():

  • Run external Python 3 scripts
  • Pass data via command line or files
  • Read results back into Ignition

3. Write it manually:

  • Implement NumPy algorithms from scratch
  • 10x more code, 10x more bugs
  • Reinventing well-tested wheels

From an Inductive Automation forum discussion about Python 2.7 limitations, Kevin Herron (Inductive Automation staff) wrote:13

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.

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


The AI Era Changed Everything

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 happened.

Suddenly, Python engineers had AI pair programmers writing code alongside them. Productivity went through the roof. But here's the thing: this productivity boost is highly language-dependent.

How AI Code Assistants Work

Large Language Models (LLMs) like GPT-4, Claude, and GitHub Copilot's Codex are trained on massive amounts of publicly available code:

  • 60 million Stack Overflow posts14
  • 2.7 terabytes of source code across 350+ programming languages15
  • GitHub's entire public repository history

But this data is heavily skewed toward popular languages.

Python's Dominance in AI Training Data

Python's presence in LLM training data:

  • Stack Overflow: Python is the #1 most-discussed language
  • GitHub: Python overtook JavaScript in 2024,16 driven by AI adoption
  • The Stack dataset: Python, Java, and JavaScript dominate

Jython 2.7's presence:

  • Stack Overflow: Minimal (mostly 2010-2015 questions)
  • GitHub: Tiny fraction (obsolete language)
  • Training datasets: Essentially zero dedicated Jython code

The Academic Research

A 2024 academic survey analyzing 111 research papers on LLM code generation found:17

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.

Bottom line: AI assistants work great for Python 3.x. They struggle with Jython and fail completely with proprietary industrial DSLs.


The Compounding Disadvantage

Let me show you what this looks like in practice.

Python 3.x Engineer with AI Assistance

Workflow:

  1. Type comment describing what you need
  2. GitHub Copilot suggests complete, correct code
  3. Review and accept suggestion
  4. Run it. Works immediately

What they get:

  • ✅ Intelligent autocomplete (trained on billions of lines of Python)
  • ✅ ChatGPT/Claude can write complex functions
  • ✅ Stack Overflow answers copy/paste perfectly
  • ✅ AI suggests appropriate libraries (NumPy, Pandas, etc.)
  • ✅ Error messages → instant Stack Overflow solutions
  • ✅ AI can refactor and optimize code

Estimated productivity multiplier: 2-5x vs manual coding18


Jython 2.7 Engineer with "AI Assistance"

Workflow:

  1. Type comment describing what you need
  2. GitHub Copilot suggests Python 3 code with NumPy/Pandas
  3. Try to run it → ImportError
  4. Google "Jython moving average"
  5. Find Python 3 solutions (don't work)
  6. Find Python 2 solutions (maybe work, but outdated)
  7. Eventually write it manually
  8. Debug for another 20 minutes

What they get:

  • ⚠️ Copilot autocomplete (but suggests Python 3 syntax → errors)
  • ⚠️ ChatGPT writes code (but uses libraries you can't access)
  • ❌ Stack Overflow answers use Python 3 (incompatible)
  • ❌ AI suggests NumPy/Pandas (not available)
  • ⚠️ Error messages → Python 3 solutions (don't apply)
  • ⚠️ AI refactors using features you don't have

Estimated productivity multiplier: 0.5-1.5x (AI creates confusion/wasted time)


Proprietary DSL Engineer with "AI Assistance"

Workflow:

  1. Type comment in proprietary SCADA scripting language
  2. AI has no idea what your syntax is
  3. AI suggests JavaScript-like code (completely wrong)
  4. Manually search vendor documentation (500-page PDF)
  5. Find example, adapt manually
  6. No Stack Overflow, no community help

What they get:

  • ❌ Copilot has zero training data → random suggestions
  • ❌ ChatGPT/Claude unfamiliar → hallucinations
  • ❌ No Stack Overflow → no community solutions
  • ❌ AI actively misleads (wastes hours)

Estimated productivity multiplier: 0.2-0.8x (AI makes things worse)


Real-World Productivity Comparison

Task: Calculate 10-sample moving average for vibration sensor data

Python 3.x Engineer (30 seconds):

import numpy as np

# State maintained at module level
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:]  # Keep last 10 samples
    return float(np.mean(window))

GitHub Copilot wrote this. Uses NumPy. Works perfectly. On to the next problem.


Jython 2.7 Engineer (25 minutes):

First attempt (from Copilot suggestion):

import pandas as pd  # ImportError!

Second attempt (manual implementation):

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

Manually tested. Found off-by-one error. Fixed. Works now.

Time ratio: 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: 240x slower


What About Other Industrial Programming Languages?

You might be wondering: what about IEC 61131-3 languages used in PLCs (Ladder Diagram, Structured Text, etc.)?

Recent academic research (October 2024) tested LLM support for industrial automation languages:19

Structured Text (ST):

LLM4PLC introduced syntax checkers... proving highly suitable for industrial automation applications

With fine-tuning, LLMs can generate ST code. But it requires specialized training.

Ladder Diagrams (LD):

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

Sequential Function Charts (SFC):

It is possible to generate correct SFC for simple requirements when LLMs are provided with several examples.

Here's the pattern: Industrial languages can get basic LLM support, but only if:

  • You use vendor-specific fine-tuning (like Siemens Industrial Copilot for TIA Portal)20
  • You're locked into specific platforms
  • You accept that it's still way behind Python's native LLM support

OPC Data Wrangler: Real Python for Industrial Transforms

This is exactly why we built OPC Data Wrangler.

Embedded CPython 3.12

OPC Data Wrangler embeds CPython 3.12 directly into the application. While the core platform is written in Zig for rock-solid performance, it can be extended with custom Python scripts that run in sandboxed CPython environments.

This architecture gives you:

  • NumPy works - Array operations, numerical computing
  • Pandas works - Time-series analysis, data manipulation
  • scikit-learn works - Machine learning, predictive maintenance
  • All of PyPI works - 500,000+ packages accessible
  • Real CPython - Not Jython, not a limited subset, the actual Python interpreter
  • Zig performance - Core platform runs at native speed
  • Sandboxed execution - Python scripts run safely isolated

AI Assistance Works Perfectly

Because it's real Python:

  • ✅ GitHub Copilot suggestions work immediately
  • ✅ ChatGPT/Claude code runs without modification
  • ✅ Stack Overflow answers copy/paste perfectly
  • ✅ Modern tutorials apply directly
  • ✅ Community solutions transfer

Example: Moving Average (The Right Way)

In OPC Data Wrangler's Python Transform node:

import numpy as np

# State maintained at module level
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:]  # Keep last 10 samples
    return float(np.mean(window))

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

Focused on ETL, Not Everything

OPC Data Wrangler isn't trying to be another behemoth SCADA platform. It's a narrow, modular tool focused on one job: OPC ETL and data transformation.

You get:

  1. Visual DAG Builder - Drag-and-drop nodes for common transforms
  2. Python Transform Nodes - Real CPython 3.12 when you need custom logic
  3. Mix and Match - Use visual nodes, Python, or both
  4. Portable Code - Your Python transforms are standard Python modules

The Future-Proof Choice

The Gap is Widening

Here's the thing: as LLMs improve, the productivity advantage of Python will compound:

  • More Python code on GitHub → better AI training data
  • Better training data → better AI suggestions
  • Better suggestions → more engineers choose Python
  • Cycle repeats

Meanwhile, Jython 2.7 and proprietary DSLs fall further behind:

  • No new training data (deprecated language)
  • AI suggestions don't improve
  • Gap widens every month

The 5-Year Outlook

By 2030:

  • Python 3.x + AI: 10-20x productivity vs 2025
  • Jython 2.7 + AI: Same or worse (confusion increases)
  • Proprietary DSLs + AI: Effectively zero AI assistance

If you're starting your career today and learning Jython 2.7, you're learning a dead end.

If you're learning Python 3.x, you're learning the language of AI, data science, and modern automation.


Conclusion: Choose Your Future

We're at an inflection point in industrial automation.

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

But 57-65% of Fortune 100 companies use Ignition, which runs Jython 2.7, a version that:

  • Can't use NumPy, Pandas, or ML libraries
  • Gets poor AI assistance (AI suggests code that doesn't work)
  • Teaches skills that don't transfer to the broader Python ecosystem

And the AI era made this gap 10x worse. What used to be just a library limitation turned into a full-blown productivity crisis.

OPC Data Wrangler embeds CPython 3.12:

  • Full PyPI ecosystem (all the libraries)
  • Excellent AI assistance (Copilot/ChatGPT work perfectly)
  • Future-proof skills (industry standard)
  • No workarounds needed
  • Zig-based core for native performance
  • Sandboxed Python execution for safety

The choice is simple:

  • Learn Jython 2.7 (deprecated since 2020, falling further behind)
  • Or learn Python 3.x (industry standard, AI-enhanced, future-proof)

Industrial automation deserves modern tools. Not proprietary scripting languages. Not deprecated Python variants. Just Python. The real one.


Get Started with Real Python

Try OPC Data Wrangler:

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 & 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 Blog - https://blogs.sw.siemens.com/thought-leadership/going-beyond-automation-with-the-industrial-copilot-part-2-transcript/

  21. Clarion Tech - Python Business Applications 2025

Ready for Real Python in Industrial Automation?

Stop fighting with deprecated languages and limited AI assistance. Use OPC Data Wrangler with real Python 3.x and full ecosystem access.

About the Author

Chris Laponsie founded Thingamatronics after experiencing the frustration of Jython limitations in industrial automation. OPC Data Wrangler delivers the modern Python experience automation engineers deserve.

More from the Blog

WEEK 1

The OPC UA ETL Problem Nobody Talks About

Why OPC UA ETL is about data transformation, not just data movement, and how visual DAGs with built-in unit conversions change everything.

Read Article →
WEEK 3 - COMING SOON

I Asked AI to Build My OPC Pipeline (And It Worked)

From natural language description to production DAG in 30 seconds. See the AI copilot in action.

Coming Soon