IronPython URLs

IronPython is a great cross-platform development language, running on the Microsoft .NET framework for Windows and on Mono just about everywhere. Even for CPython developers IronPython has a few features that make it of interest. These include: Under IronPython there is no Global Interpreter Lock (GIL) meaning that multi-threaded pure-Python applications can scale across multiple CPUs with no extra work from the developer .NET AppDomains allow you to create Python engines and restrict their security privileges, including controlling network and filesystem access and which assemblies the Python code can use Easily create Python applications with multiple isolated Python engines in the same process Easy to compile applications to binary and make binary only applications Through the Dynamic Language Runtime (DLR) you get interoperability with languages like C# / F# / IronRuby and IronScheme Extending IronPython with C#, for performance, is worlds easier than extending Python with C For d

It's good to have friends in high places, and two of them have reviewed IronPython in Action . Both Jonathan Hartley and Brett Cannon are experienced Python developers. Jonathan Hartley is a colleague of mine at Resolver Systems where we have been working full time with IronPython for the last few years. I finally managed to blackmail him into actually reading IronPython in Action. Despite this he seemed to genuinely enjoy it and has posted a glowing review. The first paragraphs of the review have some interesting things to say about the place of IronPython in the Python world, which is the section I've quoted below: Jonathan Hartley Reviews IronPython in Action Having spent some years working with .NET, and with a series of intriguing personal experiments in Python under my belt, I originally approached IronPython some years ago with a modicum of of trepidation. I feared that the weld between the two would be intrusively visible, forming distracting differences from regular

Castle Windsor is a popular .NET Inversion of Control container, but it can be complex to configure. A blogger, who's name I can't discover (put your name on your blogs guys!), has written two articles on using IronPython to configure Castle Windsor. Using IronPython to configure Castle Windsor I Castle Windsor is a very popular IoC container in the .Net world. Like almost all other containers it can be configured using either a fluent interface or an xml-based configuration file. The fluent interface has the advantage of being strongly typed, what spares you a lot of errors caused by typos. On the other hand, it is hard coded and can’t be changed easily without recompiling (Actually you could use an IoC container to load your IoC container configuration dynamically but it give a rise to the question: “How do you configure the container to load its own configuration?” ) The other option is to use an xml file. Despite being the most used solution in almost all containers it is

Dave Fugate, IronPython tester and the man in charge of releases, gives us an intriguing look into what is involved in releasing a new version of IronPython. Releasing software is always a pain, for any company or project, but even more so for Microsoft. A few interesting tidbits about IronPython CodePlex releases While it's still fresh on my mind, I'll share a bit of interesting info about IronPython releases. What will blow most peoples' minds is that on average it takes us about five full working days to produce and signoff on a release for CodePlex. For example, we started the release process for IronPython 2.6 Beta 2 on Friday morning and released it today. "Dave, when all you have to do is build the 'release' configuration of the sources already on CodePlex how can it possibly take this long?" you ask. Three words: testing and Microsoft bureaucracy…err I mean "Microsoft processes". What do you want to know about IronPython? Dave Fugate is a

Tony Andrew Meyer is teaching IronPython as course D520 ("Programming") at Northtec, using IronPython in Action as course material. He has been posting weekly updates of his progress including making his course notes available for download. We've covered his previous entries: Teaching IronPython: D520 weeks 2 & 3 Teaching IronPython: D520 Course Notes (Week One) Tony has now posted two more entries, on weeks four and five of the course. D520 – Week Four We basically did two things: worked through the MultiDoc example in Chapter 4, and worked on implementing the Airline lab designed in the previous week. The first recommended reading for the week was Part 1 of Joel Spolsky’s “Talk at Yale” , wherein he tries to relate his study to his career – the part I hoped they would find interesting was the discussion of “geeks” versus “suits”. The second recommended article was Steve Yegge’s “Code’s Worst Enemy” , which is mostly about code bloat. In retrospect, these might no

Another collection of blog entries and projects related to IronPython and the Dynamic Language Runtime. IronRuby 0.9 starts 6 times faster than IronPython 2.6B1, why is that? Does anyone know? IronPython 2.0 is significantly slower to start than CPython, which is an issue for those writing command line tools and full applications in IronPython. IronPython 2.6 improves the situation, but as the lament in this short blog entry expresses it is still slow even when compared to IronRuby: IronRuby 0.9 starts 6 times faster than IronPython 2.6B1 Why is that? Don’t they use the same DLR engine? If IronPython started the same way, probably I would not use ‘CPython plus .Net exposed through MSFT Com’ technique. It is just unfair. On the usual support channel ( Twitter ) Dino Viehland explained that the IronPython interpreter does a bunch of work at startup time that IronRuby doesn't. On startup the interpreter imports the site module site just like CPython (and IronPython uses site.py from

Python allows for multiple inheritance , and therefore so does IronPython. With multiple inheritance you provide multiple base classes. As member resolution is done dynamically in Python, when you call a method the class hierarchy is searched to find the correct method. With single inheritance this is straightforward (the inheritance hierarchy is a straight line), with multiple inheritance the method resolution order is used to find methods. Multiple inheritance can be very useful where you really need it, but it also complicates your code. I believe it should be used rarely, but there are plenty of Python programmers who believe it should never be used. The most common use of multiple inheritance is to provide mixin functionality. It is often used in a similar way to interfaces in languages like C#. Simon Segal has written a blog entry describing multiple inheritance in IronPython, and how it interacts with inheriting from .NET types: C# classes for Mixins and Multiple Inheritance w

A collection of blog entries and articles on IronPython and the Dynamic Language Runtime from the last few weeks. Speed Test: Reflection vs IronPython Randall Sutton was using reflection to apply rules to an object when he realised he could do it with IronPython, but he was worried about performance. He wrote a quick test to compare the performance and was surprised by the results. The first run was very expensive for IronPython, but from there on in IronPython was much faster than C#. Without expending any effort actually working it out, my guess is that because IronPython uses reflection so heavily it caches the reflection lookups - and it is this caching that is giving it the performance benefit. Reflection on .NET is not fast, by any stretch of the imagination, and improving the performance of reflection would make a big difference to speeding up DLR languages. The Silverlight Toolkit and the Dynamic Language Console The Silverlight Toolkit is an open source project by Microsoft

I'm a few weeks behind the curve on this one, but I'm finally catching up with my backlog; IronRuby 0.9 has been released. It looks like they didn't make the version 1.0 by OSCON but they have made a lot of progress. IronRuby 0.9 Released Jimmy Schementi lets us know the highlights of the new release: Library performance was a big focus for this release; basically going though the Ruby Benchmark suite and making sure any obvious slowness was fixed. As I said in my previous post about OSCON, IronRuby is approximately 2x faster than MRI when running the benchmark suite, but in the near future a complete evaluation of IronRuby’s performance will be done and published on the website. Antonio Cangiano has already published benchmark results between IronRuby 0.9 and Ruby 1.8.6, and things look really good for IronRuby. On the compatibility front, the Win32OLE Ruby library is now available in IronRuby. This builds on top of IronRuby’s existing COM interop from version 0.5, lettin

Devhawk, otherwise known as Harry Pierson, is the program manager for IronPython on the Microsoft dynamic languages team. He is a prolific, even more than me, has a whole bunch of interesting IronPython related posts that I've fallen behind on. The first set of posts is about building a hybrid Python / C# application, specifically using the awesome Pygments syntax highlighting library from a .NET application. Pygments for Windows Live Writer v1.0.2 Harry has been working on a syntax highlighting plugin for the Windows Live Writer desktop blogging tool. He's using Pygments via IronPython 2.6 Beta 2 to do the highlighting, and barring some problems with the import magic Pygments does (known by the IronPython team as “Harry’s Pygments Import Bug”) it works fine with IronPython. Building a Hybrid C# / IronPython App without Dynamic Type C# 4.0 introduces a new feature, the dynamic type, that will make embedding and interacting with dynamic languages from C# much easier. If you w

Jeff Hardy is an extremely prolific developer who has been involved in IronPython for a long time. By testing large Python frameworks and libraries with IronPython he has reported many bugs to the IronPython team. As part of this Jeff Hardy has accumulated repositories of more than a dozen different projects that he has been porting to IronPython. As you can imagine this is a lot of work and he is offering the opportunity for anyone else interested in these projects to take them on: Biting Off More Than I Can Chew I was going through the “Repositories” folder on my machine, looking at all of the stuff I’ve downloaded since, well, the last time I went through this exercise. This time around, a lot of it is stuff I’ve tried to get working on IronPython. Here’s a sampling: Django setuptools Trac Genshi Mercurial SCons CherryPy docutils moin pygments pymarkdown nose sqlalchemy IronRubyMVC On top of that, there’s the stuff I wrote: NWSGI , IronPython.Zlib , adonet-dbapi , and more . The goo

A Turkish blogger named Ibrahim Kivanc, a Microsoft student partner, has posted a series of blog entries showing off some really cool things with IronPython and Silverlight. Unfortunately (for me) the blog is in Turkish, but several of the entries have code to download. I'm listing the entries here in the order he posted them: IronPython Silverlight MultiScaleImage One of the coolest things about Silverlight is its deep zoom technology that allows web applications to zoom in and pan across large, multi-resolution images. This functionality is accessed through the MultiScaleImage class. This blog entry has XAML and IronPython code for using the MultiScaleImage from IronPython. Türkçe Chiron Chiron is the tool for developing Silverlight applications with dynamic languages. It is a server that packages apps on the fly and enables you to develop on your local filesystem: edit the Python, refresh the browser and see you changes immediately. IronPython Silverlight Animasyonlar (animati

The blog entry I'm focusing on here is in Russian. Normally this means I would mention it one of the "good mix" posts but not spend too much time on it, however it makes a useful point that I think is worth explaining: Поддержка sys._getframe в IronPython. First of all the author recommends Eclipse 3.5 , along with PyDev 1.4.7 and IronPython 2.6 Beta 2 - which in itself is an interesting combination for IronPython development. (Ironic that the big Java IDE has much better support for IronPython than the big .NET IDE.) One of the new things in IronPython 2.6, and in fact the reason that PyDev is able to have support for things like debugging IronPython code, is support for Python stack frames and APIs like sys._getframe , sys.settrace and so on. To run IronPython with this enabled you need to use a magic command line switch, of which IronPython has many. You can get a list of them by running ipy.exe -? : None of the ones above are standard to Python, although some of th

Microsoft software is not what you might expect in Debian and Fedora / Red Hat (although perhaps it's commonplace now ), but this is what C.J. Adams-Collier has been working towards. Looking to get Iron* and the DLR into RedHat I sent an email to the Fedora Legal list asking whether they will accept software released under the MS-PL license. My friend and former colleague, Brett Lentz mentioned that he was concerned that the Fedora folks might not accept software released under the MS-PL. So I asked. I also bcc’d a certain troll on said mail so as to get lots of flame mail. I’m practicing to become a master twitterbaiter. MS-PL is acceptable for Fedora as a GPL-incompatible https://www.redhat.com/archives/fedora-legal-list/2009-August/msg00017.html In addition, IronRuby/IronPython/DLR may make it in to FC 13, thanks to Brett. dlr-languages package passes another hurdle It looks like the upload of the Iron* languages to Debian is imminent. We’ve gotten the debian/watch file downloa

The July 2009 issue of Python Magazine is out, and the headline feature is an article on testing .NET applications with IronPython by the honourable Mr. Hartley . Brandon Craig-Rhodes (editor in chief) describes the article in his blog post on the July issue: The July 2009 issue of Python Magazine First, IronPython, the .NET version of Python for Windows, is the topic of Jonathan Hartley's article about acceptance testing. He illustrates that, regardless of the language in which you write your .NET application, you can deploy simple strategies to make your application testable through a Python test harness, and thereby bring Python's strong flexibility as a testing language to bear on a product that you might be writing in another .NET language. The article goes over some of the techniques we use for acceptance testing at Resolver Systems , but applies them to applications written in C# rather than IronPython.

A collection of projects, articles and blog entries on IronPython from the last few weeks. Lit S3 Commander 1.0 Lits3 is " a library written in C# that provides comprehensive and straightforward access to Amazon S3 for .NET developers ". The commander is a command line interface to LitS3, written in IronPython by Atif Aziz , and it just had a 1.0 release. Professional IronPython by John Paul Meuller This is a book by John Wiley due out on 20th April 2010. I can't find any other references to it on the net other than this Amazon.co.uk page, but it's been up for a while. Paperback: 504 pages Publisher: John Wiley & Sons (20 April 2010) ISBN-10: 0470548592 ISBN-13: 978-0470548592 I've not crossed paths with John Paul Meuller in the IronPython community, but it seems he's written quite a few technical books . Silverlight Spy with DLR Integration Silverlight Spy is a tool for doing runtime inspection of Silverlight applications: "Use the built

Gestalt is a new project by Microsoft MIX labs that uses Silverlight to allow you to use Python and Ruby to script the browser in the same way that you use Javascript. It is open source and has a home on codeplex: Gestalt codeplex site Gestalt.js is a library released by MIX Online Labs that allows you to write Ruby, Python & XAML code in your (X)HTML pages. It enables you to build richer and more powerful web applications by marrying the benefits of expressive languages, modern compilers, AJAX & RIAs with the write » save » refresh development model of the web. Gestalt is a way of building more powerful web applications without changing the way you work. Learn more Gestalt is built on IronRuby and IronPython for Silverlight This CodePlex project makes available the sample and source code for Gestalt. Gestalt is still young but Steve Gilham has been trying out the beta: Gestalt -- first experiences The Python-in-the-page concept for Mix's Gestalt is great -- but as a beta

Tony Andrew Meyer has now been teaching course D520 ("Programming") at Northtec, using IronPython in Action as course material, for three weeks now. He's been writing up how its going and posting the course notes online (week one described here ), and weeks two and three are now up: D520 Week Two Here’s my material from the second week of “D520: Programming” (in IronPython). The students got some brief notes [PDF] and the first proper lab exercise [PDF]. The recommended reading this week was a post by Lukas Mathis about poor hardware design (and lessons to be learnt), and a post by Wil Shipley about tracking down a Delicious Library bug. The notes are again in four sections: textbook chapters (this week chapter 3, which is fairly essential reading), tools (same as last week, although I also recommended IronPython 2.6b2), key points, and example code (from chapter 3 of the textbook). D520 Week Three When planning the semester’s schedule for D520, I choose a few topics