Hubbry Logo
IronPythonIronPythonMain
Open search
IronPython
Community hub
IronPython
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
IronPython
IronPython
IronPython
View on Wikipedia
from Wikipedia
IronPython
Original authorsJim Hugunin, Microsoft
DevelopersDino Viehland,
.NET Foundation
Initial releaseSeptember 5, 2006; 19 years ago (2006-09-05)[1]
Stable release
3.4.2 / December 20, 2024; 13 months ago (2024-12-20)
Preview release
3.4.0-beta1 / April 30, 2022; 3 years ago (2022-04-30)
Repository
Written inC#
Operating systemWindows, Linux, macOS
Platform.NET Framework, .NET, Mono
TypePython programming language implementation
LicenseApache License 2.0
Websiteironpython.net Edit this on Wikidata

IronPython is an implementation of the Python programming language targeting the .NET and Mono frameworks. The project is currently maintained by a group of volunteers at GitHub. It is free and open-source software, and can be implemented with Python Tools for Visual Studio, which is a free and open-source extension for Microsoft's Visual Studio IDE.[2][3]

IronPython is written entirely in C#, although some of its code is automatically generated by a code generator written in Python.

IronPython is implemented on top of the Dynamic Language Runtime (DLR), a library running on top of the Common Language Infrastructure that provides dynamic typing and dynamic method dispatch, among other things, for dynamic languages.[4] The DLR is part of the .NET Framework 4.0 and is also a part of Mono since version 2.4 from 2009.[5] The DLR can also be used as a library on older CLI implementations.

Status and roadmap

[edit]

Jim Hugunin created the project and actively contributed to it up until Version 1.0 which was released on September 5, 2006.[6] IronPython 2.0 was released on December 10, 2008.[7] After version 1.0 it was maintained by a small team at Microsoft until the 2.7 Beta 1 release. Microsoft abandoned IronPython (and its sister project IronRuby) in late 2010, after which Hugunin left to work at Google.[8] The project is currently maintained by a group of volunteers at GitHub.

  • Release 2.0, released on December 10, 2008, and updated as 2.0.3 on October 23, 2009, targets CPython 2.5.[9] IronPython 2.0.3 is only compatible up to .NET Framework 3.5.
  • Release 2.6, released on December 11, 2009, and updated on April 12, 2010, targets CPython 2.6.[10] IronPython 2.6.1 versions is binary compatible only with .NET Framework 4.0. IronPython 2.6.1 must be compiled from sources to run on .NET Framework 3.5. IronPython 2.6.2, released on October 21, 2010, is binary compatible with both .NET Framework 4.0 and .NET Framework 3.5.
  • Release 2.7 was released on March 12, 2011 and it targets CPython 2.7.[11]
  • Release 2.7.1 was released on October 21, 2011 and it targets CPython 2.7.[12]
  • Release 2.7.2.1 was released on March 13, 2012. It enables support for ZIP file format libraries, SQLite, and compiled executables.[13]
  • Release 2.7.4 was released on September 7, 2013.[14]
  • Release 2.7.5 was released on December 6, 2014 and mostly consists of bug fixes.[15]
  • Release 2.7.6 was released on August 21, 2016 and only consists of bug fixes.[16]
  • Release 2.7.7 was released on December 7, 2016 and only consists of bug fixes.[17]
  • Release 2.7.8 was released on February 16, 2018 and consists of bug fixes, reorganized code, and an updated test infrastructure (including significant testing on Linux under Mono). It is also the first release to support .NET Core.[18]
  • Release 2.7.9 was released on October 9, 2018 and consists of bug fixes, reorganized code. It is intended to be the last release before IronPython 3.[19]
  • Release 2.7.10 was released on April 27, 2020 and adds .NET Core 3.1 support.[20]
  • Release 2.7.11 was released on November 17, 2020 and resolves issues when running on .NET 5.
  • Release 2.7.12 was released on January 21, 2022 and resolves issues with .NET 6 and removes support for .NET core 2.1[21]
  • Release 3.4.0 was released on December 12, 2022 and is the first release to support Python 3.x. [22]

Differences with CPython

[edit]

There are some differences between the Python reference implementation CPython and IronPython.[23] Some projects built on top of IronPython are known not to work under CPython.[24] Conversely, CPython applications that depend on extensions to the language that are implemented in C are not compatible with IronPython ,[25] unless they are implemented in a .NET interop. For example, NumPy was wrapped by Microsoft in 2011, allowing code and libraries dependent on it to be run directly from .NET Framework.[26]

Silverlight

[edit]

IronPython is supported on Silverlight (which is deprecated by Microsoft and already has lost support in most web browsers[27]). It can be used as a scripting engine in the browser just like the JavaScript engine.[28] IronPython scripts are passed like simple client-side JavaScript scripts in <script>-tags. It is then also possible to modify embedded XAML markup.

The technology behind this is called Gestalt.[citation needed] 

<!-- DLR initialization script. -->
<script src="http://gestalt.ironpython.net/dlr-latest.js" type="text/javascript"></script>

<!-- Client-side script passed to IronPython and Silverlight. -->
<script type="text/python">
    window.Alert("Hello from Python")
</script>

The same works for IronRuby.

License

[edit]

Until version 0.6, IronPython was released under the terms of Common Public License.[29] Following recruitment of the project lead in August 2004, IronPython was made available as part of Microsoft's Shared Source initiative. This license is not OSI-approved but the authors claim it meets the open-source definition.[30] With the 2.0 alpha release, the license was changed to the Microsoft Public License,[31] which the OSI has approved. The latest versions are released under the terms of the Apache License 2.0.

Interface extensibility

[edit]

One of IronPython's key advantages is in its function as an extensibility layer to application frameworks written in a .NET language. It is relatively simple to integrate an IronPython interpreter into an existing .NET application framework. Once in place, downstream developers can use scripts written in IronPython that interact with .NET objects in the framework, thereby extending the functionality in the framework's interface, without having to change any of the framework's code base.[32]

IronPython makes extensive use of reflection. When passed in a reference to a .NET object, it will automatically import the types and methods available to that object. This results in a highly intuitive experience when working with .NET objects from within an IronPython script.

Examples

[edit]

The following IronPython script manipulates .NET Framework objects. This script can be supplied by a third-party client-side application developer and passed into the server-side framework through an interface. Note that neither the interface, nor the server-side code is modified to support the analytics required by the client application. 

from BookService import BookDictionary
 
booksWrittenByBookerPrizeWinners = [book.Title for book in BookDictionary.GetAllBooks() 
                                    if "Booker Prize" in book.Author.MajorAwards]

In this case, assume that the .NET Framework implements a class, BookDictionary, in a module called BookService, and publishes an interface into which IronPython scripts can be sent and executed.

This script, when sent to that interface, will iterate over the entire list of books maintained by the framework, and pick out those written by Booker Prize-winning authors.

What's interesting is that the responsibility for writing the actual analytics reside with the client-side developer. The demands on the server-side developer are minimal, essentially just providing access to the data maintained by the server. This design pattern greatly simplifies the deployment and maintenance of complex application frameworks.

The following script uses the .NET Framework to create a simple Hello World message. 

import clr
clr.AddReference("System.Windows.Forms")

from System.Windows.Forms import MessageBox
MessageBox.Show("Hello World")

Performance

[edit]

The performance characteristics of IronPython compared to CPython, the reference implementation of Python, depends on the exact benchmark used. IronPython performs worse than CPython on most benchmarks taken with the PyStone script but better on other benchmarks.[33] IronPython may perform better in Python programs that use threads or multiple cores, as it has a JIT compiler, and also because it doesn't have the Global Interpreter Lock.[34][35]

Overview and key features

[edit]
  1. Integration with .NET: IronPython allows you to use .NET libraries and frameworks directly in your Python code. This means you can leverage the extensive .NET ecosystem and access features that are specific to .NET environments.
  2. Dynamic Language Runtime (DLR): IronPython runs on the Dynamic Language Runtime, which is a set of services that support dynamic typing and dynamic method invocation in .NET languages.
  3. Interoperability: You can call .NET code from IronPython and vice versa. This makes it possible to integrate Python scripts with existing .NET applications or use .NET components within Python projects.
  4. Syntax and Semantics: IronPython aims to be as close as possible to the standard Python language (CPython), though there might be minor differences due to the underlying .NET platform.
  5. Performance: While IronPython provides good performance for many applications, it might not be as fast as CPython for some tasks, particularly those that rely heavily on Python's native libraries.
  6. Compatibility: IronPython is compatible with Python 2.x, but it does not support Python 3.x features. This means that some newer Python libraries or syntax may not be available.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

IronPython

View on Grokipedia
from Grokipedia
IronPython is an open-source implementation of the Python programming language that targets Microsoft's .NET Framework, providing tight integration with the .NET ecosystem. It enables Python code to directly access the full range of .NET libraries and allows .NET applications written in languages like C# to embed and execute Python scripts seamlessly. Originally created in 2005 by Jim Hugunin as a proof-of-concept to demonstrate running Python on the .NET Common Language Runtime (CLR), IronPython was adopted by Microsoft in 2006 when they hired Hugunin and incorporated it into the development of the Dynamic Language Runtime (DLR). Microsoft continued active development until October 2010, after which they transferred the project to the open-source community under the leadership of developers like Jeff Hardy. Since then, IronPython has been maintained by the IronLanguages organization on GitHub, with ongoing releases supporting both Python 2.7 (latest version 2.7.12 from January 2022) and Python 3.x (latest version 3.4.2 from December 2024). IronPython compiles Python source code to .NET intermediate language (IL) for execution on the CLR, ensuring high performance while maintaining compatibility with standard Python syntax and semantics. Key features include bidirectional , where Python can import and use .NET assemblies as if they were native modules, and .NET code can invoke Python functions dynamically. It supports .NET Core and .NET Standard for cross-platform compatibility and is licensed under the Apache License 2.0, making it suitable for both commercial and open-source projects. Primarily used for scripting, , testing, and embedding dynamic in .NET applications, IronPython bridges the Python and .NET communities effectively.

Overview

Definition and Purpose

IronPython is an open-source implementation of the Python programming language designed specifically for the .NET ecosystem. It provides a tightly integrated environment where Python code can natively access and utilize .NET libraries, while also allowing .NET applications to incorporate Python scripts and modules. As of December 2024, the latest IronPython release (3.4.2) targets Python 3.4, with a parallel branch supporting Python 2.7 (latest 2.7.12 from January 2022); compatibility includes .NET Framework 4.6.2, .NET Standard 2.0, .NET Core, .NET 6.0, .NET 8.0, .NET 9.0, and Mono, enabling seamless execution of supported Python code within diverse .NET platforms. The primary purpose of IronPython is to bridge the gap between Python's dynamic, interpretive and .NET's robust, statically typed framework, facilitating hybrid development in enterprise settings. This integration supports , scripting, and the creation of mixed-language applications where Python's flexibility enhances .NET's and , such as leveraging extensive .NET APIs for or UI development without requiring language-specific wrappers. IronPython was initially released on September 5, 2006, by developer Jim Hugunin, marking the first stable version of this .NET-targeted Python implementation. At a high level, IronPython's architecture leverages the Dynamic Language Runtime (DLR), a set of services built atop the Common Language Runtime (CLR) to host dynamic languages efficiently. The DLR enables features like dynamic type systems, expression trees for code generation, and optimized method dispatching, allowing IronPython to compile Python abstract syntax trees into intermediate language code that runs on the CLR while maintaining Python's semantic behaviors.

Key Features

IronPython provides seamless access to .NET libraries, allowing Python scripts to and utilize .NET assemblies directly through mechanisms such as the clr module and AddReference function, enabling developers to leverage the extensive .NET ecosystem without additional wrappers or bindings. This integration facilitates the use of .NET classes, methods, and events within Python , promoting between Python and languages like C# or VB.. Unlike , IronPython operates without a (GIL), inheriting the .NET Common Language Runtime's (CLR) robust multi-threading capabilities, which allows multiple Python threads to execute concurrently and fully utilize multi-core processors. This absence of the GIL enhances performance in threaded applications, making IronPython particularly advantageous for concurrent programming tasks on .NET platforms. IronPython 3.x fully supports Python 3 syntax and a of the , incorporating .NET-specific extensions that extend functionality, such as improved handling of strings. It maintains compatibility with many third-party Python packages while augmenting them with .NET equivalents where beneficial. The implementation is cross-platform, running on Windows, , and macOS through support for .NET Core and .NET 6 or later, ensuring broad deployment flexibility across operating systems without sacrificing .NET integration. IronPython preserves Python's dynamic model, including , by mapping it onto the .NET via the Dynamic Language Runtime (DLR), which enables flexible, late-bound operations while ensuring compatibility with statically typed .NET components.

History

Origins and Early Development

IronPython was initiated by Jim Hugunin, the creator of —a Python implementation for the —in 2003 as a personal prototype to evaluate the .NET Common Language Runtime (CLR) as a platform for dynamic languages. Hugunin, then an independent developer, aimed to demonstrate the CLR's shortcomings for such languages but discovered unexpected potential during the prototyping phase, shifting his focus toward building a viable Python runtime on .NET. This early work was inspired by preliminary explorations of dynamic code generation and binding mechanisms that would later influence the Dynamic Language Runtime (DLR). The primary goals of this initial development were to enable seamless Python execution within .NET environments, facilitating better integration with Windows-specific tools, , and the broader .NET ecosystem, where CPython's C-based extensions often posed compatibility challenges. By targeting the CLR, IronPython sought to address these limitations, allowing Python developers to leverage .NET libraries directly without bridging overhead, while providing a managed runtime that could benefit from .NET's garbage collection and security features. Hugunin's experience with informed the , emphasizing compatibility with core Python semantics alongside .NET from the outset. The project gained after Hugunin joined in 2004, but its foundational prototypes remained independent efforts until formal sponsorship. The first , IronPython 1.0, occurred on September 5, 2006, implementing the core features of Python 2.5 and marking a stable milestone for early adopters in .NET-heavy development contexts. This version supported an interactive console, dynamic compilation, and access to .NET assemblies, laying the groundwork for broader adoption prior to deeper corporate integration.

Microsoft Involvement

In 2004, Microsoft hired Jim Hugunin, the original creator of IronPython, to enhance the .NET Framework's support for dynamic languages, and the project was integrated into Microsoft's Dynamic Language Runtime (DLR) team. This acquisition marked the beginning of official Microsoft stewardship, with IronPython serving as a key testbed for DLR features like dynamic typing and expression trees. Under this team, development accelerated, focusing on tighter integration with .NET tools and libraries. Microsoft's involvement led to several major releases, including IronPython 2.0 in December 2008, which achieved full compatibility with Python 2.6 and introduced seamless integration with for , , and . Subsequent versions, such as 2.6 in December 2009 and 2.7 in April 2011, further aligned IronPython with CPython's 2.x series, enhancing support and performance optimizations via the DLR. During this period, IronPython also enabled Python scripting in Silverlight applications, allowing dynamic in browser-based .NET environments from 2007 onward. Microsoft's peak contributions culminated in these 2.6 and 2.7 releases, which represented the height of official investment in and tooling. However, in October 2010, Microsoft ceased active development, transitioning the project to open-source under the 2.0 and handing maintenance to the community. This shift ended 's direct role, though the foundational work during this era solidified IronPython's position within the .NET ecosystem.

Post-Microsoft Era

Following Microsoft's decision to end active development in October 2010, IronPython transitioned to an independent open-source project relicensed under the Apache 2.0 license, allowing . The was subsequently hosted on under the IronLanguages , with repositories established between 2011 and 2012 to facilitate collaborative development. This shift marked the beginning of volunteer-led maintenance, focusing on preserving .NET integration while addressing evolving Python standards. A key community achievement was the addition of compatibility with the cross-platform runtime, initially introduced in IronPython 2.7.8 released in February 2018, and expanded in subsequent versions like 2.7.10 in April 2020, 2.7.11 in November 2020, and 2.7.12 in January 2022 to support 3.1, .NET Standard, and later versions. This migration enabled IronPython to run on non-Windows platforms, broadening its applicability beyond the traditional . Efforts toward Python 3 compatibility culminated in the project's first stable 3.x release, IronPython 3.4.0, on December 12, 2022, targeting Python 3.4 semantics with support for .NET Framework 4.6.2, .NET Core 3.1, and .NET 6. Subsequent updates included 3.4.1 in July 2023 and 3.4.2 in December 2024, incorporating bug fixes and enhanced library compatibility. As of 2025, IronPython's development remains volunteer-driven through pull requests and issues, with contributions emphasizing incremental improvements and compatibility enhancements despite a modest pace.

Current Status and Roadmap

Maintenance and Community

IronPython's development is governed as an open-source project under the Apache 2.0 license, maintained by a core team of contributors through the IronLanguages organization. The primary repositories are hosted on GitHub at IronLanguages/ironpython3 for the Python 3.x implementation and IronLanguages/ironpython2 for the Python 2.x branch, where code, documentation, and release artifacts are managed collaboratively. Releases are distributed via multiple channels, including NuGet packages for easy integration into .NET projects, MSI installers for Windows (primarily for the 2.x series), and ZIP archives available directly from GitHub. The project maintains a slow but steady pace of activity, with the latest stable release, IronPython 3.4.2, issued on December 19, 2024, targeting .NET Framework 4.6.2, .NET Standard , .NET 6.0, .NET 8.0, and compatible with .NET 9. In 2025, development has continued with occasional commits addressing bug fixes and minor enhancements, alongside resolutions to select open issues, reflecting ongoing but limited maintenance efforts. This measured activity stems from the project's transition to community-driven stewardship following its open-sourcing by in 2010. The IronPython community remains small yet dedicated, comprising developers interested in .NET-Python , with contributions welcomed for bug reports, fixes, and feature proposals via pull requests. Discussions and support occur primarily through informal channels, including the [ironpython] tag on for technical questions, threads in subreddits like r/dotnet, and the project's for real-time . The official website, ironpython., serves as a central hub for announcements, downloads, and documentation, though it does not host dedicated forums. Support for IronPython relies on community self-help, with GitHub issues serving as the main venue for reporting and tracking bugs, particularly challenges related to non-Windows platforms like and macOS compatibility. There is no formal paid support , emphasizing the project's volunteer-led and encouraging users to engage directly with the contributor base for assistance.

Development Targets and Future Plans

IronPython's primary development target remains full compliance with the Python 3.4 , including its reorganized structure, strings, and core semantics, while selectively incorporating features and behaviors from later Python 3.x versions to enhance compatibility where possible. This approach ensures that most Python 3.4 syntax and modules function as expected, though full equivalence with is not guaranteed due to underlying .NET integration. Alignment with the .NET ecosystem is a key focus, with ongoing support for .NET Framework 4.6.2, .NET Standard 2.0, .NET 6.0, .NET 8.0, and compatibility with .NET 9, extending to future .NET to maintain in modern development environments. Efforts emphasize cross-platform stability, enabling deployment on Windows, , and macOS, although non-Windows platforms may encounter occasional bugs stemming from the project's historical Windows-centric testing. As of 2025, no formal long-term roadmap has been published for IronPython, with development priorities centered on bug fixes, operational parity across supported operating systems, and incremental enhancements potentially drawing from Python 3.5 and subsequent releases. Progress is entirely volunteer-dependent, contributing to a measured pace of updates that limits comprehensive adoption of advanced features from Python 3.12 and later. The project's challenges are primarily resource-related, as a small of contributors handles amid competing priorities, resulting in partial or absent support for certain later Python 3.x elements, such as full async/await integration, and incomplete coverage of the evolving Python ecosystem beyond 3.4 baselines.

Technical

Dynamic Language Runtime

The Dynamic Language Runtime (DLR) is a runtime environment developed by that extends the (CLR) of the .NET Framework to support dynamic languages, providing services such as expression trees, call site caching, and dynamic binding for seamless integration with .NET components. Expression trees represent code as data structures that capture language semantics, including and assignments, while call site caching optimizes repeated dynamic operations by storing type information and operation details for faster subsequent executions. The DLR's binding mechanisms encapsulate language-specific rules, enabling interoperability between dynamic languages and statically typed .NET libraries. In IronPython, the DLR serves as the foundational host for the Python parser, compiler, and executor, transforming Python abstract syntax trees (ASTs) into DLR-compatible expressions for execution on the CLR. It facilitates late binding and dynamic method resolution through dynamic sites, which perform runtime lookups and cache results based on object types, such as generating specialized sites like DoOperation-Add-0 for efficient arithmetic operations. This architecture allows IronPython to leverage the CLR's just-in-time () compilation for optimized performance on repeated code paths. Key components of the DLR in IronPython include binders that map .NET types to Python semantics, ensuring transparent access to .NET assemblies during execution. Additionally, much of IronPython's is implemented in C# rather than Python, compiling to intermediate language (IL) for native .NET performance and direct utilization of the Base Class Library (BCL). For instance, the re module for regular expressions is built in C# using System.Text.RegularExpressions. IronPython has been built on the DLR since its early development in , aligning with the runtime's initial release to enhance dynamic language support on .NET. Subsequent updates have extended compatibility to .NET Core and .NET Standard, with IronPython 2.7.10 introducing support in 2020 and later versions like 3.4.2 targeting .NET 6.0 and .NET 8.0 for modern cross-platform deployment.

Python Compatibility Layers

IronPython achieves compatibility with by reimplementing key components of the Python in C#, allowing Python code to run with minimal modifications while integrating seamlessly with the .NET ecosystem. Core modules such as those for file I/O (e.g., using System.IO equivalents) and threading (e.g., leveraging System.Threading) are ported to utilize .NET primitives, ensuring that standard Python operations map to efficient underlying platform capabilities. This approach covers essential functionality from the Python 3.4 , enabling portability for pure Python scripts without native extensions. The implementation provides full support for the syntax and semantics of Python 3.4, including advanced language features like and comprehensions, function and class decorators, and metaclasses for customizing class creation. IronPython's parser generates an (AST) that adheres to Python 3.4 grammar rules, preserving behaviors such as , context managers, and generator expressions as defined in the language specification. This fidelity allows developers to write idiomatic Python code that executes identically to in supported scenarios. At the core of this compatibility is a custom object model that maps Python types and behaviors to .NET constructs via the Dynamic Language Runtime (DLR). Python objects, such as dynamic instances with arbitrary attributes, are represented using DLR's expression trees and dynamic sites, which handle attribute access, method calls, and at runtime. For instance, dynamic attribute assignment in Python is emulated through DLR's binding mechanisms, caching type-specific operations for performance while maintaining Python's loose typing semantics. This mapping ensures that Python's capabilities, like dict and getattr, function as expected. IronPython's version alignment is fixed to Python 3.4 features, incorporating the reorganized , Unicode strings by default, and all stable syntax elements up to that release, but excluding experimental or post-3.4 additions like async/await keywords or f-strings. This deliberate scoping prioritizes stability and full conformance to a specific Python version, facilitating reliable code portability within that boundary.

Differences from

Extension and Library Compatibility

IronPython, implemented on the .NET runtime via the Dynamic Language Runtime (DLR), is fundamentally incompatible with extensions that rely on the C , as it lacks direct support for C-level interfaces like those used in modules such as and . This incompatibility arises because IronPython does not embed the interpreter or expose the same C , preventing seamless loading of compiled extensions designed for . As a result, scientific computing libraries like , , and , which depend heavily on C extensions for performance, cannot be used directly and often require full rewrites in .NET languages or alternative implementations. Pure Python libraries, lacking C dependencies, generally integrate well with IronPython, provided they avoid constructs like ctypes for calling external C libraries, which may encounter loading issues due to .NET's managed environment. For instance, the requests library can function in older versions compatible with Python 2.7, but newer releases face challenges from dependencies like urllib3 or six that assume -specific behaviors. IronPython's support aligns closely with 2.7 (for IronPython 2.x) and 3.4 (for IronPython 3.x, latest 3.4.2 as of December 2024) for pure Python components, enabling use in scripting and web tasks where such modules predominate. To address these limitations, developers can employ workarounds such as the Ironclad library, a community project that provides a partial compatibility layer, allowing transparent import of select compiled extensions by emulating the necessary interfaces on .NET. Alternatively, IronPython's built-in clr module facilitates access to .NET equivalents, such as using System.Data for data manipulation in place of or Math.NET Numerics as a substitute for functionality. Experimental integrations via Python.NET have also enabled limited C extension access by embedding wrappers, though these remain non-standard and require careful configuration. These compatibility constraints particularly impact domains like scientific computing and , where C-accelerated libraries are essential, limiting IronPython's adoption there in favor of environments dominated by pure Python code, such as scripts or web prototyping.

Behavioral and Performance Divergences

IronPython diverges from in its threading model due to the absence of a (GIL), allowing true parallel execution of Python threads across multiple CPU cores without the serialization imposed by 's GIL. This leads to different outcomes in multi-threaded applications, where threads are limited to concurrent execution but not parallelism for tasks, whereas IronPython can achieve actual parallelism, potentially altering program behavior in scenarios involving shared mutable state or race conditions. For instance, CPU-intensive threaded computations in IronPython may complete faster and with less contention, though this requires careful to avoid unexpected interactions not present in . Integer handling in IronPython leverages the .NET runtime's arbitrary-precision integers, implemented via System.Numerics.BigInteger, contrasting with CPython's native long type that also supports arbitrary precision but uses a distinct internal representation optimized for the C-based interpreter. This integration means IronPython integers seamlessly interoperate with .NET libraries expecting BigInteger, but may exhibit subtle behavioral differences in overflow handling or performance for very large values compared to CPython's approach, where integers transition from fixed-width int to long without explicit type boundaries in Python 3. Such divergences can affect numerical computations involving extensive arithmetic, though both implementations maintain Python's semantic guarantee of unlimited size. Exception handling in IronPython aligns closely with .NET's exception model to facilitate interoperation, creating paired Python and .NET exception objects when errors occur across language boundaries, which can alter propagation compared to CPython's purely Python-centric mechanism. In mixed Python-.NET code, an unhandled .NET exception may raise a corresponding Python Exception subclass, potentially bypassing CPython-style finally blocks or context managers in edge cases, leading to different stack trace reporting or cleanup behavior. This design enhances seamless integration but requires developers to account for .NET-specific exception hierarchies when porting CPython code. Other behavioral differences include string handling: IronPython uses UTF-16 encoding for str (unlike CPython's UTF-32 in Python 3), resulting in surrogate pairs for characters > U+FFFF (length 2 in IronPython vs. 1 in CPython) and different encoding of invalid surrogate pairs. Codec behaviors vary, such as single-byte codecs (e.g., ) using "best fit" mappings in IronPython while treating unused positions as invalid in CPython, and always terminating Base64 blocks with '-' in IronPython (optional in CPython). OS interactions differ in environment variable handling, with IronPython using 'replace' error mode (replacing invalid bytes with U+FFFD) instead of CPython's 'surrogateescape'. Recursion defaults to throwing a .NET StackOverflowException, though a limit can be set via command-line options like ipy -X MaxRecursion=100. IronPython also lacks full support for Unix-style signal handling in the signal module, as the .NET runtime does not expose equivalent signals, limiting -compatible use for interrupts or alarms in cross-platform scripts. Performance characteristics of IronPython stem from its reliance on the .NET Just-In-Time () compiler, resulting in slower startup times due to initial runtime loading and code compilation overhead, unlike 's immediate interpretation. However, once running, IronPython often outperforms in loops or operations invoking .NET methods, as these calls avoid marshalling overhead and benefit from optimizations tailored to the host platform. Edge cases highlight further divergences, such as floating-point precision, where IronPython adheres strictly to .NET's double-precision format, which may yield minor representational differences from CPython's C double implementation on certain platforms due to compiler variances.

.NET Integration

Interoperability Mechanisms

IronPython facilitates seamless interaction between Python code and .NET components through the (CLR), enabling Python scripts to leverage the full breadth of .NET libraries and frameworks. The primary entry point for this is the clr module, which provides essential functions for loading .NET assemblies and bridging the two environments. To import .NET assemblies, developers first execute import clr to access the CLR integration layer. Core assemblies such as mscorlib and System are pre-loaded automatically, allowing immediate use without additional steps. For other assemblies, the clr.AddReference function dynamically loads them by name or file path, such as clr.AddReference('System.Xml') for XML processing capabilities or clr.AddReference('assembly.dll') for custom DLLs. This process exposes the assembly's contents as Python-accessible modules, integrating .NET metadata directly into the Python namespace. Accessing .NET types from IronPython involves importing namespaces and classes as Python modules and objects, treating them as native Python entities while retaining .NET behaviors. For instance, after loading the System assembly, Python code can instantiate classes like Console via from [System](/page/System) import Console, followed by method calls such as Console.WriteLine('Hello') to output text to the console. This syntax supports , polymorphism, and static members, allowing Python to subclass .NET types and override methods transparently. Data marshalling in IronPython occurs automatically during interactions, converting between Python and .NET types to minimize developer overhead. Python lists map to .NET IEnumerable or arrays, strings to System.String, integers to System.Int32, and dictionaries to IDictionary, with bidirectional support for return values. More complex types, like Python tuples, convert to .NET tuples or object arrays, while .NET enums and value types integrate as Python equivalents. This conversion layer, powered by the Dynamic Language Runtime (DLR), ensures and performance without explicit casting in most cases. Calling conventions enable bidirectional execution, where Python functions can be invoked from C# or other .NET languages via DLR hosting APIs. In a .NET application, the IronPython.Hosting provides a ScriptEngine to create execution scopes, load Python scripts, and retrieve functions as dynamic objects or delegates for direct calls. Python functions further support conversion to .NET delegates using clr.ConvertToDelegate, allowing assignment to event handlers or callbacks, such as wiring a Python to a .NET button's Click event. This mechanism preserves Python's dynamic nature while adhering to .NET's for events and delegates.

Interface Extensibility

IronPython enables Python developers to extend .NET functionality by implementing interfaces defined in C# or other .NET languages, allowing seamless integration of Python logic into .NET ecosystems. Python classes can directly inherit from .NET interfaces using standard inheritance syntax, with method implementations resolved dynamically at runtime by the Dynamic Language Runtime (DLR). For instance, a Python class can implement the System.ICloneable interface as follows:

python

import System class MyClass(System.ICloneable): def __init__(self, value): self.value = value def Clone(self): return MyClass(self.value)

import System class MyClass(System.ICloneable): def __init__(self, value): self.value = value def Clone(self): return MyClass(self.value)

This creates an object that conforms to the interface, enabling its use in .NET code expecting ICloneable implementations. The DLR further supports the creation of runtime proxies for .NET types, facilitating dynamic interception and customization of method calls with Python callbacks. By leveraging DLR's expression trees and dynamic object services, developers can generate proxy instances that wrap .NET objects, injecting Python-defined behavior such as logging or validation without modifying the original types. This capability stems from the DLR's core features, which allow for late-bound operations and extensible meta-objects, making suitable for aspect-oriented extensions in .NET applications. Event handling provides another layer of extensibility, where Python functions can subscribe to .NET events using familiar operator syntax. .NET events are exposed as objects supporting __iadd__ and __isub__ methods, permitting the use of += and -= for attachment and detachment. A practical example involves monitoring file system changes:

python

from System.IO import FileSystemWatcher watcher = FileSystemWatcher(".") def on_created(sender, event_args): print(f"Created: {event_args.Name} ({event_args.ChangeType})") watcher.Created += on_created watcher.EnableRaisingEvents = True

from System.IO import FileSystemWatcher watcher = FileSystemWatcher(".") def on_created(sender, event_args): print(f"Created: {event_args.Name} ({event_args.ChangeType})") watcher.Created += on_created watcher.EnableRaisingEvents = True

This allows Python code to respond to .NET events in real-time, enhancing interactive .NET applications like UI components. IronPython offers full support for (COM) interop, enabling Python scripts to instantiate and manipulate COM objects through mechanisms like System.Type.GetTypeFromProgID or interop assemblies, which treat properties and methods as Python attributes. However, support for (WinRT) is partial, constrained by IronPython's reliance on .NET Framework or .NET Core runtimes, which lack native WinRT projections without additional bridging; this limits direct access in scenarios compared to full .NET languages.

Performance Analysis

Benchmark Comparisons

IronPython's performance in standard benchmarks reveals trade-offs inherent to its integration with the .NET runtime, often lagging behind in pure Python execution while gaining advantages in .NET-interfacing scenarios. In the PyStone benchmark, which measures synthetic CPU performance, historical tests from around 2010 showed IronPython 2.x results comparable to or slightly better than 2.x in some configurations. However, IronPython generally performs worse than modern versions like 3.12 on PyStone, reflecting ongoing optimizations in 's interpreter. Recent benchmarks for IronPython 3.4 are limited. The Richards benchmark, a CPU-bound task simulating concurrent task scheduling, highlights similar disparities; IronPython has been slower than CPython in historical runs, though it outperforms in .NET-heavy workloads where native interop minimizes overhead, such as calling .NET APIs directly without marshalling costs. Startup time represents a notable drawback for IronPython, typically slower than CPython due to the initial loading of the .NET Common Language Runtime (CLR) and assemblies. This penalty may be mitigated in later .NET versions, though benefits for IronPython's dynamic code are limited. As of 2009, IronPython underperformed relative to in pure Python benchmarks, with executing tasks faster in Java-interop light scenarios, though both trailed in raw speed. Recent comparisons are unavailable. Comparisons with enhanced by are not directly feasible, as IronPython lacks native support for 's C extensions, rendering incompatible without viable wrappers; projects like Ironclad are outdated.

Threading and Scalability Benefits

IronPython's implementation on the .NET (CLR) eliminates the (GIL) present in , enabling true multi-threading where multiple Python threads can execute simultaneously across all available CPU cores. This absence of the GIL stems from IronPython's reliance on the thread-safe libraries and runtime of .NET, unlike CPython's C-based extensions that necessitate the lock to prevent race conditions in . As a result, tasks in IronPython can achieve parallel execution, providing a significant advantage over CPython's effective single-core limitation for such workloads. Through its seamless .NET integration, IronPython allows developers to leverage the Task Parallel Library (TPL) for implementing asynchronous and parallel operations directly in Python code. For instance, TPL constructs like Parallel.ForEach can be invoked from IronPython scripts to process collections in parallel, enhancing efficiency for both CPU-intensive computations and I/O-bound tasks without the concurrency restrictions imposed by CPython's GIL. This integration supports advanced patterns such as task continuations and cancellation tokens, making it particularly suitable for responsive applications involving . In scalability contexts, IronPython excels in high-concurrency environments like web servers built with , where .NET's robust threading model and automatic handle enterprise-level loads effectively. The CLR's garbage collector optimizes across threads, reducing overhead in scenarios with numerous simultaneous requests, such as dynamic web applications or services. Community reports indicate improved multi-threaded performance in IronPython compared to , particularly in environments utilizing multiple cores for parallel processing.

Applications and Examples

Historical Deployments

IronPython was notably deployed in Silverlight applications for dynamic scripting within browser-based .NET applications from 2007 to 2012, enabling developers to build interactive user interfaces incorporating Python logic alongside Silverlight's multimedia capabilities. This integration leveraged the Dynamic Language Runtime (DLR) to host IronPython scripts directly in Silverlight environments, facilitating of rich web experiences such as animated controls and event-driven behaviors without requiring full recompilation. In enterprise scripting contexts, IronPython integrates with tools like and Revit for automation scripts, allowing users to extend CAD functionalities through Python-based macros and plugins that interact with the .NET API. For instance, Revit's macro system uses IronPython 2.7 to execute scripts for tasks such as model manipulation and parameter adjustments, providing a more accessible alternative to C# for non-programmers in architectural workflows. Following the deprecation of Silverlight, with announcing no further major versions after Silverlight 5 in 2011 and full end of support on October 12, 2021, IronPython's role in such browser-centric deployments diminished significantly. Remaining legacy uses persist in on-premise .NET Framework applications, where IronPython continues to serve as an embedded scripting engine for .NET 4.6.2 and earlier environments, particularly in internal tools and legacy automation systems. Niche adoptions of IronPython included early game development via the XNA Framework, where it was explored as a scripting alternative to C# for prototyping game logic and behaviors in Windows-based titles during the late 2000s. Developers embedded IronPython scripts into XNA projects to handle dynamic elements like AI behaviors or UI interactions, capitalizing on its interpretive nature for iterative testing without frequent rebuilds. IronPython continues to see use in contemporary engineering and development tools. In simulation software, such as Workbench, Mechanical, and Discovery, IronPython serves as the basis for scripting to automate workflows, interact with .NET/Mono assemblies, and extend simulation capabilities, with support ongoing as of 2025. Additionally, provides project templates for IronPython applications, enabling .NET interop and mixed-mode debugging, facilitating its use in modern .NET development environments as of 2024.

Practical Code Examples

IronPython's practical utility is best illustrated through executable code snippets that leverage its seamless integration with the .NET Framework. These examples assume IronPython 3.x running on a .NET environment, such as Windows with or the IronPython standalone installer. A foundational example demonstrates importing .NET assemblies and invoking basic console output, showcasing IronPython's ability to blend Python syntax with .NET functionality.

python

import clr clr.AddReference('System') from System import Console Console.WriteLine('Hello from IronPython!')

import clr clr.AddReference('System') from System import Console Console.WriteLine('Hello from IronPython!')

This script loads the System assembly via the clr module and uses the Console class to print to the standard output, confirming IronPython's runtime initialization and .NET interop. For deeper .NET integration, IronPython enables direct access to data access libraries like System.Data.SqlClient for database operations. The following snippet establishes a connection to a SQL Server instance and executes a simple query, illustrating how Pythonic code can manipulate .NET objects without additional wrappers.

python

import clr clr.AddReference('System.Data') from System.Data.SqlClient import SqlConnection, SqlCommand connection_string = 'Server=(localdb)\\mssqllocaldb;Database=TestDB;Trusted_Connection=True;' conn = SqlConnection(connection_string) conn.Open() cmd = SqlCommand('SELECT COUNT(*) FROM Users', conn) result = cmd.ExecuteScalar() print(f'Number of users: {result}') conn.Close()

import clr clr.AddReference('System.Data') from System.Data.SqlClient import SqlConnection, SqlCommand connection_string = 'Server=(localdb)\\mssqllocaldb;Database=TestDB;Trusted_Connection=True;' conn = SqlConnection(connection_string) conn.Open() cmd = SqlCommand('SELECT COUNT(*) FROM Users', conn) result = cmd.ExecuteScalar() print(f'Number of users: {result}') conn.Close()

This example requires a valid and an existing database; it queries a hypothetical "Users" table and retrieves the row count, highlighting IronPython's support for providers. IronPython lacks the Global Interpreter Lock (GIL) present in CPython, allowing true parallelism in multi-threaded CPU-bound tasks via the standard threading module. The demo below spawns multiple threads to perform independent computations, demonstrating scalable execution across cores.

python

import threading import time def compute_sum(n): total = sum(range(n)) print(f'Thread {threading.current_thread().name}: Sum = {total}') threads = [] for i in range(4): t = threading.Thread(target=compute_sum, args=(1000000,)) threads.append(t) t.start() for t in threads: t.join() print('All threads completed.')

import threading import time def compute_sum(n): total = sum(range(n)) print(f'Thread {threading.current_thread().name}: Sum = {total}') threads = [] for i in range(4): t = threading.Thread(target=compute_sum, args=(1000000,)) threads.append(t) t.start() for t in threads: t.join() print('All threads completed.')

Each thread calculates the sum of a large range independently, with output varying by thread name; this leverages .NET's threading model for concurrent execution without serialization. Exception handling in IronPython accommodates both Python and .NET exceptions uniformly within try-except blocks, facilitating robust error management across the ecosystem. Consider this example that attempts a .NET arithmetic operation and catches the corresponding exception.

python

import clr clr.AddReference('System') from System import Decimal, DivideByZeroException try: result = [Decimal](/page/Decimal)(10) / [Decimal](/page/Decimal)(0) except DivideByZeroException as e: print(f'Caught .NET exception: {e.Message}')

import clr clr.AddReference('System') from System import Decimal, DivideByZeroException try: result = [Decimal](/page/Decimal)(10) / [Decimal](/page/Decimal)(0) except DivideByZeroException as e: print(f'Caught .NET exception: {e.Message}')

The division triggers a DivideByZeroException from the .NET [Decimal](/page/Decimal) type, which is imported and caught specifically, printing the error message while preventing program termination.

Licensing and Distribution

License History

IronPython's licensing origins trace back to its creation in 2005 by Jim Hugunin, who released the initial versions under personal permissive terms that allowed open-source distribution but were tailored specifically to him as the author. These early releases were experimental and aimed at demonstrating Python's viability on the .NET Framework, with permissive conditions that facilitated community access without formal corporate oversight. Following Hugunin's recruitment to Microsoft in 2006, IronPython's version 1.x releases adopted the Shared Source for IronPython, a permissive that permitted commercial and noncommercial use, modification, and distribution while retaining control over key aspects such as grants limited to the software itself. This marked IronPython's integration into 's ecosystem, emphasizing rapid iteration toward a stable 1.0 release while requiring retention of copyright notices and providing no warranties. With the release of IronPython 2.x starting in , the project transitioned to the Microsoft Public License (Ms-PL), an OSI-approved permissive license that broadened contributor involvement by granting royalty-free rights to reproduce, modify, and distribute the software, though it maintained 's influence through explicit patent protections and trademark restrictions. The Ms-PL applied through 2010, supporting versions up to 2.6 and enabling tighter .NET interoperability during this period of active Microsoft development. In July 2010, Microsoft relicensed IronPython under the 2.0 in response to community preferences, shifting to a fully OSI-approved open-source model that explicitly allowed broad commercial use, patent grants without termination risks from litigation, and compatibility with diverse ecosystems. This change coincided with IronPython 2.7 Alpha 1 and facilitated the project's move to in 2011 under the IronLanguages , decentralizing maintenance and enhancing collaborative contributions.

Current Terms and Availability

IronPython is distributed under the 2.0, which grants users a perpetual, worldwide, non-exclusive, no-charge, license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute the software in source or object form, including for commercial purposes. This license requires that notices, the original license terms, and any conditions regarding grants be retained in any redistributed copies, along with attribution to the .NET Foundation and contributors if applicable. It provides the software on an "as is" basis, disclaiming all warranties, express or implied, including those of merchantability, fitness for a particular purpose, and non-infringement, while limiting liability for any damages arising from its use. Binaries for IronPython are available through releases, including MSI installers for Windows, ZIP archives for cross-platform use, DEB packages for Debian-based distributions, and PKG installers for macOS. For integration into .NET projects, IronPython is distributed as a package, enabling easy embedding of the IronPython engine via tools like the .NET CLI or . The complete source code is hosted on , allowing users to clone the repositories, build from source using provided scripts such as make.ps1, and customize as needed. Direct installation via pip install ironpython is not supported, as IronPython is not hosted on PyPI; instead, users must download binaries or use .NET tooling like dotnet tool install --global ironpython.console for console access. Development occurs across separate repositories for distinct Python versions: the ironpython2 repository maintains the legacy Python 2.7 implementation, while ironpython3 focuses on active development for Python 3.x, currently targeting compatibility with Python 3.4 and incorporating features like strings and a reorganized . The latest release in the Python 3.x branch is version 3.4.2 (December 2024), with binaries supporting .NET Framework 4.6.2 and later, as well as .NET Core and .NET 5+ runtimes. IronPython's Apache 2.0 license is compatible with the under which much of the .NET ecosystem is released, permitting seamless integration without additional licensing conflicts. There are no specific restrictions on usage with .NET Core or later versions, and it supports deployment on .NET 6.0, .NET 8.0, and equivalent Mono runtimes across Windows, , and macOS platforms. Once installed, package management within IronPython environments is handled via ipy -m pip, allowing installation of compatible Python modules in user-global, project-local, or virtual environments.

References

  1. https://ironpython.net/
  2. https://github.com/IronLanguages/ironpython3
  3. https://ironpython.net/documentation/dotnet/
  4. https://github.com/IronLanguages/ironpython2/releases/tag/ipy-2.7.12
  5. https://arstechnica.com/information-technology/2006/09/5205/
  6. https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/october/clr-inside-out-ironpython-and-the-dynamic-language-runtime
  7. https://wiki.python.org/moin/GlobalInterpreterLock
  8. https://aosabook.org/en/v2/ironlang.html
  9. https://qconlondon.com/london-2009/qconlondon.com/dl/qcon-london-2009/slides/MichaelFoord_RealWorldIronPython.pdf
  10. https://ironpython-test.readthedocs.io/en/latest/license.html
  11. https://www.infoq.com/news/IronPython/
  12. https://learn.microsoft.com/en-us/archive/blogs/hugunin/
  13. http://hugunin.net/microsoft_farewell.html
  14. https://www.infoq.com/news/2008/12/IronPython-2/
  15. https://learn.microsoft.com/en-us/archive/msdn-magazine/2006/october/clr-inside-out-ironpython
  16. https://www.infoq.com/news/2011/04/IronPython-2.7/
  17. https://learn.microsoft.com/en-us/archive/msdn-magazine/2008/february/clr-inside-out-dynamic-languages-and-silverlight
  18. https://github.com/IronLanguages/ironpython2
  19. https://github.com/IronLanguages/main/releases
  20. https://github.com/IronLanguages/ironpython3/releases
  21. https://www.nuget.org/packages/IronPython
  22. https://github.com/IronLanguages/ironpython2/releases
  23. https://github.com/IronLanguages/ironpython3/releases/tag/v3.4.2
  24. https://github.com/IronLanguages/ironpython3/commits/main
  25. https://stackoverflow.com/questions/tagged/ironpython
  26. https://www.reddit.com/r/dotnet/comments/1j067x6/is_ironpython_dead/
  27. https://gitter.im/IronLanguages/ironpython
  28. https://github.com/IronLanguages/ironpython3/issues
  29. https://github.com/IronLanguages/ironpython3/wiki/Differences-from-CPython
  30. https://github.com/IronLanguages/ironpython3/wiki/Package-compatibility
  31. https://learn.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/dynamic-language-runtime-overview
  32. https://stackoverflow.com/questions/6855211/can-i-use-all-standard-python-libraries-with-ironpython-or
  33. https://github.com/IronLanguages/ironclad
  34. https://stackoverflow.com/questions/29397540/how-to-install-numpy-and-scipy-for-ironpython27
  35. https://stackoverflow.com/questions/36641557/accessing-pandas-library-using-ironpython
  36. https://stackoverflow.com/questions/35162177/its-possible-to-use-requests-in-ironpython-2-7-5
  37. https://ironpython-test.readthedocs.io/en/latest/faq/library.html
  38. https://ironpython.net/documentation/dotnet/dotnet.html
  39. https://pythondotnet.python.narkive.com/FtLfKX6R/python-net-experimental-c-extensions-from-ironpython-with-python-net-code-and-article
  40. https://discourse.mcneel.com/t/numpy-and-scipy-in-rhinopython/142920
  41. https://www.quora.com/Why-do-lots-of-Python-libraries-like-NumPy-NLTK-sklearn-etc-not-work-on-IronPython
  42. https://wiki.python.org/moin/IronPython
  43. https://stackoverflow.com/questions/3429159/python-requires-a-gil-but-jython-ironpython-dont-why
  44. https://www.pypy.org/posts/2017/08/lets-remove-global-interpreter-lock-748023554216649595.html
  45. https://ironpython-test.readthedocs.io/en/latest/library/signal.html
  46. https://stackoverflow.com/questions/1015076/why-is-ironpython-startup-time-so-slow
  47. https://loosexaml.wordpress.com/2009/10/21/performance-of-ironpython-vs-c-shar/
  48. https://ironpython-test.readthedocs.io/en/latest/tutorial/floatingpoint.html
  49. https://news.ycombinator.com/item?id=1201047
  50. https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
  51. https://www.reddit.com/r/programming/comments/8mfh7/terrible_ironpython_20_and_pretty_good_jython_25/
  52. https://forums.autodesk.com/t5/revit-api-forum/python-numpy/td-p/9206138
  53. https://discourse.pyrevitlabs.io/t/ironpython-3-4-0/1310
  54. https://stackoverflow.com/questions/55841283/collecting-ironpython-parallel-loop-results
  55. https://learn.microsoft.com/en-us/dotnet/standard/parallel-programming/task-parallel-library-tpl
  56. https://www.oreilly.com/library/view/ironpython-in-action/9781933988337/ch11.html
  57. https://www.oreilly.com/library/view/ironpython-in-action/9781933988337/ch13.html
  58. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/february/dynamic-net-creating-interactive-bing-maps-with-silverlight-and-ironruby
  59. https://forums.autodesk.com/t5/revit-api-forum/python-versions/td-p/11800000
  60. https://keanw.com/2009/03/using-ironpython-with-autocad.html
  61. https://learn.microsoft.com/en-us/lifecycle/announcements/silverlight-end-of-support
  62. https://betanews.com/2007/06/08/teched-2007-ironpython-may-rival-c-for-xna-game-development/
  63. https://stackoverflow.com/questions/7768276/is-ironpython-xna-a-serious-contender-for-game-development
  64. https://developer.ansys.com/docs/command-reference-for-rigid-dynamics-systems-2024-r2/iron-python-references.md
  65. https://learn.microsoft.com/en-us/visualstudio/python/managing-python-projects-in-visual-studio?view=visualstudio
  66. https://www.red-gate.com/simple-talk/development/python/ironpython-first-steps/
  67. https://ironpython-test.readthedocs.io/en/latest/library/threading.html
  68. https://fepy.sourceforge.net/license.html
  69. https://www.zdnet.com/article/microsoft-puts-ironpython-ironruby-under-an-apache-license/
  70. https://ironpython.net/announcements/
  71. https://github.com/IronLanguages/ironpython3/wiki/Installing
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.