PYTHON AND IRONPYTHON SCRIPTING AND DEBUGGING

With the latest release of AlterNET Studio 8, we support yet another scripting engine based on Python.NET, which provides script execution and debugging capabilities for Python programming language.

It’s very similar in terms of usage to IronPython scripting engine; however, you need to consider some differences to choose one over another.

IronPython Scripting

IronPython, initially developed by Microsoft, provides execution of python code either by running it in the interpreted mode (which is used by script debugger) or generating dynamic .NET assembly on top of .NET Dynamic Language Runtime.

IronPython is fully integrated with .NET; it has a very light footprint and does not require Python to be installed on a target machine. Similarly, IronPython Standard Library Modules, such as datetime, math, etc., are implemented inside IronPython.Modules.dll and do not require additional python files. IronPython also supports multi-threaded execution.

However, due to this architecture, running IronPython script requires IL code generation and JIT-ing, which involves converting IL code into machine instructions. It may result in a noticeable start-up delay when executing large IronPython scripts. The other consideration is that IronPython supports up to 2.7 language specifications. Since the time Microsoft transferred its development to the open-source community, it’s unclear whether or not we will see support for version 3 any time soon. Finally, some popular third-party Python libraries use C-like Cython code, which IronPython does not support, which means that IronPython scripts can not use these libraries.

Python.NET Scripting

Python.NET does not have the above limitations and lags slightly behind the latest language version. Officially Python.NET can work with version 3.7 of Python language specification. It also allows the use of third-party libraries such as NumPy and Pandas and provides seamless integration with .NET assemblies (which would enable using application-defined .NET objects).

One downside we have found in Python.NET scripts compared to IronPython is that the former uses Global Interpreter Lock, which effectively means that you can not simultaneously execute multiple Python scripts in separate threads. Python.NET also relies on Python to be installed on a target machine, either in full or embedded Python distribution. We use the embedded Python distribution in our examples which does not require the user to install full Python to see how it works.

Python and IronPython script debugging

As for script debugging, both scripting engines provide identical capabilities, such as step-by-step execution, breakpoints, evaluating watches and local variables, and call stack display. It allows almost seamless integration into .NET applications - because the debugger can execute interpreted code line by line, it does not have the limitations of C# and Visual Basic debuggers.

One known issue with both engines is that the script debugging session is executed in a separate thread, which means that script needs to access application-defined objects in a thread-safe way. It means that the script has to use Invoke to access some properties of application UI controls in a thread-safe way. In the subsequent versions, we would like to handle this issue by introducing a debug message loop instead of creating a separate thread.