I guess I can paraphrase what I said on stage at the dev panel at this year's ICC, for posterity and so I can link to this in the future:
So, the question people usually ask is "When is Python 3 coming to Ignition?". But in practice, there's really two broad reasons people are actually asking that question:
- They've heard that Python 2.7 is deprecated/old/unmaintained/a security risk/whatever. But that doesn't apply to Ignition, for a few reasons:
- When folks say "Python" out in the world, they almost always mean CPython, the reference implementation of Python. It's true that this project is officially unmaintained, and security risks are more of a worry here - because the backing code is all C, which has direct access to memory and is therefore vulnerable to classes of issues like buffer overflows.
- Jython, however, is neither of those things - it's based on Java, so it's implicitly safe from memory corruption errors, and it's still maintained by a core group of contributors.
- In addition to those public fixes, Inductive Automation already has and continues to implement our own patches for issues as they are discovered, including patching potentially vulnerable standard library dependencies and fixing bugs reported by our users. This gives us the best of both worlds - we get fixes from Jython "upstream", and can implement our own.
- They want Python 3, for ecosystem compatibility, or developer experience, or whatever else. But even if Jython 3 existed and was available to us tomorrow, we still couldn't just blindly update the entire Ignition platform to Jython 3.
- It's still going to be backed by the JVM. So no compatibility with CPython extensions and their implicit reliance on C FFI - meaning no numpy, pandas, TensorFlow, etc.
- There's a huge library of customer code out there that relies on the exact semantics of Jython/Python 2.7 and its interoperability with Java. As anyone familiar with the Python ecosystem will tell you, the CPython migration from 2 -> 3 was not a painless process, and this would be just as bad.
All that said, we (Inductive Automation) are absolutely aware that we can't just keep coasting on Jython 2.7 forever. Currently, the prevailing internal opinion is that once a suitable alternative is available, we'll come up with some parallel scripting engine/runtime, and offer both Jython 2.7 compatibility and whatever new "mode", in parallel, so that upgrades can continue to be seamless but users can take advantage of the new engine.
It's also important to underscore that not all of the obstacles here are purely technical. "Polyglot" engines that can interpret and run multiple guest languages (Javascript, Python 3, Ruby, Kotlin), such as GraalVM exist - but whatever engine we choose is going to be a choice for the long haul; we take backwards compatibility very seriously at IA, so whatever we offer has to be something we're comfortable supporting for at least the next decade - and there are certain licensing albatrosses around GraalVM in particular that make it an uncomfortable choice right now.