IronPython URLs

PyCon 2010 , the annual international Python conference is coming soon (February 17th 2010 in Atlanta US). The schedule of talks is now up, and as usual there are several IronPython related talks . 67. IronPython Tooling  By Dino Veihland, core IronPython developer: One of the most popular requests for the IronPython team is tooling support. During this talk I’ll show you some of the existing tools available to help create IronPython applications. I’ll also look at the latest IronPython features which can help you debug, profile and improve your applications. I’ll also compare and contrast these with the solutions available for CPython that you may already be familiar with. 71. Python in the Browser By Jimmy Schementi (Microsoft program manager for IronPython / IronRuby Silverlight integration): You write your server code in Python because you want to. You write your browser code in JavaScript because you have to. But with IronPython and Silverlight, you can write your brows...

PyPy is the combination of an interpreter compiler toolchain that allows you to write interpreters (Virtual Machines really) in a static subset of Python, called RPython, along with an implementation of Python in RPython. The compiler toolchain allows you to compile your interpreters for several backends. The major backends are native code, for the JVM and for the CLI (which is .NET and Mono). This allows you to maintain a single codebase and produce an interpreter that runs on all these platforms. The PyPy .NET backend is called pypy-cli. PyPy on its own runs at somewhere between the same speed as CPython and twice as slow. Because it has better garbage collection (PyPy doesn't use reference counting) there are some things it does faster but there are also places it is slower. There are various cool things about PyPy, for example it is already useful where you want a sandboxed Python interpreter. The really cool thing, and perhaps one of the driving forces for creating PyPy...

In the last couple of years or so Python has moved to the point where it has several strong and widely used implementations. The major ones, in terms of usage, are CPython, IronPython and Jython. (A full list of Python implementations is difficult because it really depends by what you mean by "Python". PyPy definitely counts of course, but is Stackless a separate implementation and what about PyMite , Shedskin , Cython , cl-python , Boo , CrossTwine , HotPy and many other projects that are partial or partially complete implementations of Python?) This changes the development of core-Python (the C implementation known as CPython) slightly. As well as being the most widely used implementation CPython also serves as the reference implementation for the others. Brett Cannon is one of the more prolific of the rag-tag bunch of developers comprising the core development team. One of his tasks has been to fully implement the Python import machinery in pure Python: importlib . impo...

Everyone loves benchmarks, even though they are usually misleading at best. Of course I'm no exception. Here are three snippets of news on IronPython performance that have surfaced over the last week or so. IronPython 2.0.1 and 2.6 Beta 1 compared to CPython and Jython ( posted to Twitpic by felipez ) on Mono revision 136556: Using the pystones benchmark IronPython on Mono clocks in faster than CPython or Jython. Nice. One particular bugbear of IronPython performance has been startup time. On 64bit Windows the startup time goes from being merely bad to positively ridiculous. This is because the .NET 64bit JIT is slow to do its job and IronPython generates a lot of code needing to be JITed at startup. A lot of work has gone into IronPython 2.6 to improve startup time (by reducing the amount of rule generation done on startup), and this blog entry Dave Fugate explains something they have done specifically to address startup perf on 64bit Windows - and shows off the results: IronPytho...

IronPython is written in C# and is an implementation of the Python programming language that runs natively on the .NET framework with full access to .NET libraries. It isn't however the only way of using Python with .NET. One disadvantage of IronPython is that unless you are using Ironclad you can't use Python C extensions with IronPython, One alternative is Python.NET . This is a version of CPython (the normal implementation of Python) which also has integration with the .NET framework. As you would expect you can use Python C extensions with Python.NET, but when you use .NET objects you aren't using them natively but are using a proxied or copied version instead. There is also a little known third option: PyPy.NET . PyPy is an extremely interesting project - it is both an interpreter compiler toolchain, allowing you to write interpreters for dynamic languages in a high level static language called RPython which is a subset of Python, and a Python interpreter written in R...

Robert Smallshire has been working on an implementation of BBC Basic written in IronPython . During development he has been disappointed with the performance of IronPython, in fact he discovered that some of his code was running massively slower than the same code on either CPython (the native implementation of Python) or Jython (the implementation for the Java Virtual Machine). He posted a series of blog entries on this where he dug deeper into the problem and eventually, with the help of the IronPython team he found a solution. I've listed the blog entries in the order they were posted; what follows is a story of performance, impressive charts and an explanation: Dismal Performance with IronPython Significant claims have been made about the performance of IronPython, notably back at its inception in 2004 when Jim Hugunin, creator of both IronPython and its cousin Jython, presented a paper on IronPython performance at PyCon. Since then, there have been numerous claims to IronPytho...

The Microsoft Lang.NET Conference 2009 has come and gone. The conference is not just about Microsoft languages and platforms, but has speakers on Smalltalk, the JVM and more: Lang.NET is a forum for discussion of programming languages, managed execution environments, compilers, multi-language libraries, and integrated development environments. It provides an excellent opportunity for programming language implementers and researchers from both industry and academia to meet and share their knowledge, experience, and suggestions for future research and development in the area of programming languages. The best news from the conference was the arrival of IronPython in Action of course. In this photo Jimmy Schementi is reading the dead-tree version: There were plenty of interesting talks. You can watch the videos here . One of the talks is about a Microsoft product which ships IronPython (another one - IronPython is turning up in more and more places in the Microsoft ecosystem): Microso...

Following hot on the heels of the 0.8 release, William has managed another update to Ironclad . Ironclad is an open source project by Resolver Systems which reimplements the Python C API to allow you to use Python C extensions from IronPython. He posted the following announcement: I'm fairly pleased to announce the release of Ironclad v0.8.1; it's not an enormous technical leap above v0.8, but it does now enables you to import and use SciPy and Matplotlib with IronPython on Win32 (with some restrictions; see project page). Downloads of the source and binaries, plus more details, are available at the Ironclad Google Code Project Page -- please do play with it, and let me know if you have any problems. It's a fairly momentous release; the reason that William is only fairly pleased maybe because the release has been eclipsed by him becoming a father! Congratulations William. The list of C extensions that have now been tried with Ironclad has now been extended to: numpy 1.2 ...

Now that Python 2.6 is out of the door the IronPython team are working on IronPython support for 2.6 features. Useful new features in Python 2.6 (or at least the ones I particularly like) include: with statement available without future import New syntax for exception handling Class decorators hasattr not discarding all exceptions Being able to provide keyword arguments after *args Getter, setter and deleter on properties (damn useful) __dir__ support In fact the last one is already available - it is analogous to the method GetMemberNames that you can implement on .NET objects to provide dynamic Python behavior for classes implemented in C#. Because it was basically already there, the IronPython team built it into IronPython 2 anyway. Now that IronPython 2 is also out of the door, the team have been working on the 2.1 branch and implementing Python 2.6 features. Of course having IronPython 2.1 tracking Python 2.6 is a recipe for confusion, so Dave Fugate asked whether t...

Python is now in a very healthy position, with several major implementations: CPython, Jython, IronPython and PyPy. Python itself is very loosely specified (can anyone point me to the documentation for the __reversed__ method for example?). The specification is partly in the documentation and partly in CPython, which is called the 'reference implementation'. This blog entry is about the different implementations of Python, which parts of Python are specification and which are implementation details and what it means to talk about the performance of Python in the light of the different implementations. Django on Jython, Python Implementations and Performance UPDATE: It turns out that documentation for __reversed__ was added to the Python 2.6 docs in January. However it (currently) incorrectly states that it is new in 2.6 when it was in fact new in Python 2.4.

IronPython is an implementation of the Python programming language written in C#, running on the Microsoft .NET framework and Mono. This naturally means that there are some differences between IronPython and CPython. The most significant differences being: IronPython uses the underlying .NET basic types. Strings are therefore Unicode by default, as they will be in Python 3. IronPython compiles Python code to .NET assemblies, and uses neither Python stack frames nor bytecode. CPython extensions written in C, using the CPython C API, don't work with IronPython (at least not until Ironclad is completed). There are several lesser differences as well. For example, did you know that CPython catches string exceptions by reference whereas IronPython catches them by value? The IronPython team have written up the differences between the two implementations and have now put them up on wiki pages: Differences between IronPython 1.0.x and Python 2.4.3 Differences between IronPython 1.1.x and P...

In September 2006 Sun hired two JRuby developers to improve the story of dynamic languages on the JVM. This was seen by many as both long overdue and a response to Microsoft developing IronPython (and the Dynamic Language Runtime) for .NET. As Jython has been around for longer than JRuby, many in the Python community wondered why Sun weren't supporting Python. Finally they have answered, by hiring Ted Leung and Jython lead developer Frank Wierzbicki. On his blog Ted says: "there will be at least two of us working on Python related stuff. That includes Jython, Python support for Netbeans, and some other stuff that we haven’t quite figured out yet. We definitely will be looking for things that we can do to support CPython and the Python language as a whole. This is not just about Python on on the JVM. Sun will try to make its platforms, OpenSolaris and the JVM, the best place to develop and deploy Python applications." Frank says: Sun Microsystems has hired me to work f...

Resolver Systems has announced a new Open Source project, to get some essential CPython extensions working seamlessly with IronPython: Resolver Open Source Project: CPython Extensions from IronPython

'Someone' (moreati?) over on the 'Misspelled nemesis club' blog has started a Python implementations matrix (spreadsheet). This tracks the different versions and implementations of Python (CPython, Jython, IronPython and PyPy) and what features and libraries they support: The Python Implementations Matrix This is a great idea, but is far from being complete.

Python.NET is a project that hasn't had much publicity since IronPython became popular. Python.NET is a build of CPython with support for .NET, meaning that you can use .NET assemblies with ordinary Python (overcoming some of the limitations of IronPython - like the non-availability of C extensions). There was recently an announcement (dated July 29th) about progress: Good evening Python for .NET users! I've a list of great news for you. In the past weeks I've spent some time in fixing and enhancing PythonNet. Summary: PythonNet now works with Python 2.4 and 2.5. Python 2.6 compatibility is already prepared. A bunch of small bugs were fixed and some new features implemented. Generics, overloading and variable parameter function should work better. PythonNet also works under Un*x and Mono with UCS 2 and UCS 4 builds of Python. Two unit tests are currently failing. The source repository contains project files for MS Visual Studio and MonoDevelop. The clr module provides new...

Brendan Eich has announced three new Mozilla projects: Brendan's Roadmap: New Projects These are 'Action Monkey', 'Screaming Monkey' and 'Iron Monkey'. They are all to do with integrating 'Tamarin' (the bytecode JIT VM that Mozilla was 'given' by Adobe) into Firefox. All three projects are led by experienced Pythonistas. 'Iron Monkey' is led by Seo Sanghyeon, and involves bringing IronPython to run on Tamarin! Tamarin:IronMonkey