Comparison of IronPython and cPython¶

There are some small differences and Incompatibilities between IronPython and standard Python (“cPython”). Some are direct errors in IronPython and should be removed in future versions. However, others are considered “implementation details” and will remain. Some of them are very challenging topics.

The difference that is most obvious for users is the handling of strings. Original cPython has two different string types for byte strings and Unicode strings. This concept is similar to the data types STRING and WSTRING in IEC. IronPython simply uses .NET strings that are always Unicode-capable and use UTF-16 internally. However, IronPython implements a trick to hide the difference to cPython from the programmer. (Interesting is that the developers completely reengineered string handling for the new Python version 3. A module was developed that is much closer to that of IronPython. Afterwards, only Unicode strings are used and there is an individual data type for handling raw bytes.)

Python modules that are written in C cannot be imported into IronPython because cPython uses internal data structures that are completely different from IronPython. Most of the standard library modules were reimplemented in IronPython. However, some modules (such as the TK interface) are not available as long as they are not ported to IronPython explicitly. On the other hand, IronPython provides access to .NET assemblies including the .NET framework (as shown above), which more than compensates for this feature.

While cPython uses reference counting and a deterministic garbage collector for cleaning up cyclic garbage, IronPython relies on the non-deterministic .NET garbage collector. In most cases, this difference does not matter. But when you open files or other resources from the Python standard library or the .NET framework, you should make sure to close them later. It is best to use the with statement with the Python context manager or .NET IDisposable instances.