You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
slozier edited this page Apr 27, 2025
·
6 revisions
Note
For differences between IronPython 2 and 3 see Upgrading from IronPython2. This page describes breaking changes between releases of IronPython 3.
IronPython 3.4
IronPython 3.4 incorporates the Python Standard Library released with CPython 3.4 and generally the language features of Python 3.4, however some language features from later Python versions may be implemented as well, especially if they are backward-compatible, that is, they do not introduce incompatibilities with Python scripts expecting Python 3.4. However, sometimes this is not desirable or possible to maintain, usually due to a bug that needed to be fixed, increased compatibility with existing 3rd party Python packages, or a general need of the maintenance of the IronPython code base. To facilitate upgrades between IronPython 3 versions, this document keeps track of such breaking changes.
Breaking changes to the .NET API
Added CodeContext parameter
In a number of cases, public methods or constructors have an additional parameter of type CodeContext added (as the first parameter). To have the same behaviour as in an earlier version that did not have this parameter, use IronPython.Runtime.DefaultContext.Default as the first argument, or provide appropriate code context if preferred.
For instance, the signature of the contructor of PythonTuple (which is the class implementing the Python tuple type) after 3.4.2 has changed from:
The C# code that was using this constructor now must provide a context as the first argument. This context may be used to iterate the object provided as the second argument to initialize the tuple. To have the same behaviour as in the version 3.4.2 and before, use IronPython.Runtime.DefaultContext.Default as argument, although this may not always be the optimal context to use.
Obsolete APIs
PythonOps
The PythonOps.Call* APIs are obsolete and will be removed in a future release. Please use the PythonCalls.Call* APIs directly instead.