There are some really great functions that were added to the Python library since ver 2.5 (currently supported by Ignition). Are there any plans to update Ignition to use a more recent version of Python? Any expected release timeframe? 
Thanks!
Jython 2.7 was just announced. You can voice your support for the upgrade here: ideas.inductiveautomation.com/fo … jython-2-7, although it’s not really necessary because the upgrade is going to happen either way
Unfortunately the timeline is likely to be Ignition 7.9.
Great to hear it is going in. Thanks.
any word on upgrading to Python 3.1?
It would be really helpful to use some of the newer features, unless there is a case/switch statement available in 2.7?
Ignition uses Jython, because it needs to run on a jvm. The latest version of python that Jython implements is 2.7.
Which means that for Ignition to upgrade to python 3, Jython would need to upgrade to python 3. That's entirely out of IA's control.
Isn't Jython an IA scripting engine/language? How is it out of their control?
That's too bad.
That's not IA.
4 Likes
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.
22 Likes
IA adds some patches to the official jython 2.7 open source project. Jython is officially under the Python Software Foundation umbrella, last I checked.
This seems completely good and wise to me.
Here we are a year and a half later. While you can't commit to an alternative now, it would be helpful if you committed to choosing an alternative by a certain date, to make sure you live up to the "we can't just keep coasting on Jython 2.7 forever" take that I completely agree with.
There is no alternative that fits into the Ignition environment and exposes java resources to the extent jython does. I don't believe IA will be able to change this as long as Ignition is based on the JVM.
I don't see how IA could possibly commit to a decision deadline before there is even a glimmer of a hope of an acceptable alternative.
(IA doesn't really do deadlines anyways.)
2 Likes
I'm just some guy. While scripting is my nominal area of expertise, and I'll certainly be involved in any technical decisions, as mentioned above this is more than a purely technical decision.
<Disclaimer>
This is not an actually informed opinion, just an educated guess:
I would expect some kind of announcement or at least acknowledgement of the situation at this years ICC. Anything that's formally announced at ICC will make it into a blog post of some kind, and that's as close to a 'timeline' as you're going to get.
</Disclaimer>
9 Likes
I don't see a compelling alternative scripting engine right now either. Python via GraalVM looks great but I don't want anything to do with Oracle and don't believe for a second that project won't get killed or encumbered with nasty licensing some day.
JetBrains has backed away from encouraging Kotlin as a scripting language.
Other Python-on-JVM implementations aren't as compelling and basically add a big native dependency because they're just executing CPython, which isn't ideal.
Some kind of Lua implementation might be neutralish but then you get no library ecosystem.
A custom scripting language implementation would be a lot of work but at least we'd be responsible for it long term. Again with the library ecosystem though. At best you'd get Java libraries.
10 Likes
i.....uh....am i forgetting who owns the JVM?
The context of the sentence is that Graal is owned by Oracle. Whom, once people are entrenched in using it, will try to monetize it.
Yes, you are.
Oracle is largely the steward of the language, and they release Oracle JDK and Open JDK, neither of which we use.
But they don't "own" the JVM. It's all GPLv2.
2 Likes
Yep, so I am
I do wish Sun still existed and Java was in their hands, though 
3 Likes