Tuesday, September 30, 2008

Unit Testing in Python

The "Test Driven Developer", a .NET developer, has been using IronPython - and is "having a good time testing code with its built-in unit test framework".

He posts some example code with tests using the unittest module:
"This example should illustrate that we can write some unit tests for our Python code fairly easily and quickly. It's nice to have a built-in framework for unit testing. There is also a "doctest" module available for doing more like system testing."

IronPython Talks to Google AppEngine

Joseph Jude has continued his experimenting with his time tracking tool and getting a desktop application (written in IronPython of course) - a time tracking tool - to use google authentication via the AppEngine.
He has made a new release of the client side tool, with configuration details to talk to his appspot application (the desktop tool can be used standalone without communicating with the server):

"I had the idea of having a server which will act as a centralized data repository - laptop/desktop tool, mobile tool should send data to the server and data will be analyzed in the server."

"Next steps? Incorporate with Google Charts to provide some neat analytics reports, so that it really becomes an useful tool."

Friday, September 26, 2008

Spider Python: Some Notes on IronPython

Some person on the internet has been learning IronPython. In order to learn IronPython he has ported a simple web spider (from a language called Retlang) and posted the Python code:
He is normally a C# developer (but he has tried Boo). He has also posted some notes on his first impressions of Python:
  • Python list comprehensions can do the same as LINQ for simple cases, but LINQ is much more powerful, and it supports deferred execution, while list comprehensions are evaluated greedily. (Ed: generator expressions are evaluated lazily in Python)
  • Every description of the python syntax I ever see emphasizes the fact you don't need to put in braces. Pity they don't spend more time telling you that you have to put in colons, that would actually be useful knowledge. This really bit me when I learnt boo, which is syntactically very similar.
  • IronPython 1.0 targets CPython 2.4. This sounds fine until you realize that this was released in 2004. A fair bit has happened since then, not limited to the introduction of an inline if syntax. (Ed: IronPython 2 is Python 2.5 which is still the stable current version of Python)
  • While we're on the subject, the inline if (defaultValue if condition else exceptionValue) is actually quite cool.
  • The fairly lax approach to types means I don't need to call .Cast anymore.
  • Tabs are the devil as far as indents in Boo and Python are concerned. I highly recommend using something that shows tabs explicitly, and then eliminating the lot.
  • Instance methods that explicitly take self feels awkward to me.
  • Static Methods that require an incantation such as "ToAbsoluteUrl = staticmethod(ToAbsoluteUrl)" also feels pretty awkward. (Ed: staticmethod can be used as a decorator which is much nicer)
  • The casting to delegate isn't quite as slick as it is in C#. Passing in "spiderTracker.FoundUrl" instead of "lambda url: spiderTracker.FoundUrl(url)" results in an extremely unhelpful runtime error.
  • The lambda syntax is pretty elegant, but so is C#3's. Indeed, C#3 seems to have the edge.
  • Python's regular expressions are powerful, but not quite as good as .NET's. In particular search does what you'd expect match to do
  • findall doesn't return matches. Rather, it returns the value of the first group of the matches. This is often actually what you wanted, but it's a bit peculiar. The semantics of "Matches" in .NET are much easier to understand.
  • It did seem rather slow compared to the C# version. There are, of course, way too many variables here to make a final judgement, but it was disappointing.
He does have some quibbles with the error reporting. He's posted some screenshots of particularly crpytic tracebacks:

Surprised While Porting to IronPython 2

Ronnie Maor has blogged about his experiences of porting an IronPython 1 codebase to IronPython 2. The biggest change of course is the hosting API - which has changed completely. From the inside it is "just Python" and so the only changes should be fewer (and different) bugs. However, there are few subtle changes - like the ordering of essentially unordered collections like the dictionary and set - that revealed "hidden assumptions" in his code and tests:
My conclusions from this are:
  1. If it's not tested it doesn't work. And when you change the environment under which your code runs you need to retest.
  2. The unit tests paid off again, since they allowed me to find many problems in places I didn't expect.
  3. I need to do more to flush out these hidden assumptions. One way is to add a randomized test that runs over longer periods and plays with some variables. I could easily randomize the order in which I go over the checks, inject random errors (the system is supposed to be self healing) or delays in some strategic points, etc. The not-so-easy part is verifying the system behaved correctly, and being able to reproduce problems once they surface.
  4. Would be really good if I had code coverage tools. Don't think there's anything available for IPy :-(
  5. This happens every time I port non-trivial code. Need to stop being surprised :-)

Thursday, September 25, 2008

Should Python Projects Support IronPython and Jython?

The maintainers of the Spring Framework for Python (Spring Python) wonder how much of a priority it is to have compatibility with platforms other than CPython. In other words, should they support IronPython and Jython - and if so what should they do about their C extension dependencies?

This question sparks a good discussion and is relevant to many other Python projects and applications:
"One of the topics on my mind recently, as we consider refactoring the core container, is how we ensure that when we introduce internal dependencies, such as possibly the Amara libraries for XML processing, what secondary constraints we might be introducing."

"For example, Amara represents a very pythonic and therefore simple to read and use approach to developing XML processing, such as our very own XML application configuration parsers. So from that perspective, things are very attractive. But then you ask the question, "can I run this on another python platform, such as IronPython and Jython?" and things get more constraining."

"However, my question is "is this important, in this case?" It's a general question for the Spring Python community really. Should we attempt to support the execution of SP applications on other platforms than CPython?"

"My feelings right now are that it is unlikely that a Spring Python application developer would expect to take their entire application as is and expect to run it on a different platform, such as .NET or Jython in the JVM. If I was going to do that, I would want to take advantage of the bits and pieces that are there in the .NET and Java worlds, and that would mean a port. It's also unlikely that I would necessarily get a business requirement to shift platforms like that... but I'm open to arguments there."

"My take is that Spring.NET provides Spring for the .NET community. Spring Java, well, it does the same for the Java community. Spring Python is doing the same for the Python community. The programming model and approach is portable, but it's not expected that the actual codebase is. Think of this as the concepts are the same, but exactly how you implement them would take full advantage of the platform you are on."

"So is this fair? This is where I need the community to chime in. Are my assumptions here wrong? Is there a defined need, special to the Python community, to come up with a framework that is truly portable at the implementation level, or is the goal really to create a framework that helps us use Spring concepts in the Python world. It's a BIG question, because it informs many of the core containers development choices, hence I thought it was time to get it out there for everyone to have their say."

Assorted Snippets

Here are a collection of recent blog entries that feature IronPython but don't quite qualify for an IronPython-URLs entry of their own.

Starting with two new pages on the IronPython Cookbook:
A short recipe by Davy Mitchell that ensures user input is valid as a possible filename, removing invalid characters.
An entry by Dan Eloff demonstrating performance profiling for IronPython Silverlight applications.

Steve Gilham has been doing some odd things. Notably creating Java libraries in Java and Scala and then running them on .NET using the IKVM cross-compiler. I haven't been tracking them on this blog because most of the experiments have only been tangentially related to IronPython, but his latest entry is interesting. Here he is writing Scala (a very statically typed language for the Java Virtual Machine) code and using it from IronPython:
Which of course begs the question why?... it's still cool though.

UPDATE: In a new post Steve attempts to answer my question as to why he is doing this (and corrects my assumption that he is using IKVM to cross-compile Scala): Why am I doing this sort of thing?

Mitch Barnett has produced a promotional video (complete with rousing soundtrack) for his web based IronPython / DLR IDE the Global System Builder:

Running Python from C#

Mark Bloodworth (a Microsoft Architect Evangelist no-less!) posts a code snippet showing how to execute Python code from C# with the IronPython hosting API:
Embedding IronPython in .NET applications (or even embedding new Python engines in IronPython applications) is extremely simple to do. This means that providing user scripting, or even making part of an application dynamic, is much easier than it ever has been.

Mark says:

"I’m impressed that C# and IronPython can interact like this. The possibilities for extending applications with runtime dynamic code are intriguing - worth looking into."

Wednesday, September 24, 2008

NWSGI 0.5 Released

Alongside the new IronPython / ASP.NET release is progress with another web framework for IronPython - NWSGI.

NWSGI is a .NET implementation of the Python Web Server Gateway Interface specification. It is implemented as an ASP.NET HttpHandler with the goal of allowing you to run Python web applications / frameworks (such as Django, Trac etc) with the IIS 7 web server.

This latest release is version 0.5 and has a couple of new features and breaking changes. Jeff Hardy announces and explains the release on his blog:
Jeff also outlines his plans for the future of NWSGI:

"I'm working on building an IIS7 admin interface for all of this; it's a bit of a mess right now because the advanced UI tricks aren't really documented that well. I'm hoping to have the IIS7 admin and the installer ready by the time IronPython goes 2.0."

IronPython and ASP.NET Integration Updated

The IronPython ASP.NET integration has been updated! The new home for "ASP.NET Dynamic Languages Support" is the ASP.NET Codeplex page:
Jimmy Schementi (responsible for the Dynamic Languages and Silverlight integration but who has also worked on this project along with David Ebbo and Phil Haack) is excited and invites you to join the party:
The new refresh includes support for using IronPython with 'normal' ASP.NET (webforms - but now updated to IronPython 2) and with the new ASP.NET MVC framework. For the MVC framework, IronPython is currently only integrated into the Views and not yet Controllers or Models.

There are samples plus documentation available and Jimmy's blog entry walks through creating an IronPython webforms site with Visual Studio.

Phil Haack, who is now PM for the ASP.NET Dynamic Language Support along with ASP.NET MVC, has also blogged about the new release:
This initial release targets IronPython first - IronRuby support will follow soon...

At least one Python blogger is excited by the news. Alcides Fonseca says:

Tuesday, September 23, 2008

Passing Keyword Args to C# Methods from IronPython

Python has very useful constructs for accepting variable number of positional and keyword arguments:

def f(*args, **keywargs):

The arguments are collected as a tuple and a dictionary. C# can collect an arbitrary number of arguments to a method (no messy functions in this language!) as an array (with the params keyword) - but it has no concept of keyword arguments let alone collecting them as a dictionary.

In this blog entry Srivatsn (IronPython tester) introduces the 'ParamDictionaryAttribute' that is part of the Dynamic Language Runtime ane explains how to use it to write C# classes that can take arbitrary number of keyword arguments:

Game Scripting in IronPython

Calbert has written a MUD type game with C# and IronPython on the server, with the user interface in Silverlight.

"I wanted to explore this scripting for Perenthia because I want to be able to add dynamic functions or scripts to objects. I wrote this sample to test out using C# as base classes for IronPython classes and passing operations back and forth between the two. As such the source is kind of loose but the concepts are demonstrated.

What I have is a basic framework of C# classes that define an Actor (any object in the game), a Client (a connected player), a Game (the logic of the game) and a Server (for handling HTTP communication, etc.). The Actor, Client and Game classes also server as the base classes for IronPython classes or Creatures, NPCs, Players and Rooms."

In his blog entry he shows some of the C# classes and how they are used from IronPython.

Monday, September 22, 2008

DLR Namespace Change Fire Drill

The other significant change in IronPython 2 Beta 5 was a namespace change for one of the core assemblies: Microsoft.Scripting.Core.dll

At the heart of the Dynamic Language Runtime are expression trees - the Abstract Syntax Trees of DLR languages. Another part of the .NET framework (at least since .NET 3.5) is LINQ - Language Integrated Query. LINQ makes querying a first class language concept. In its most basic form (over objects) it resembles Python list comprehensions and generator expressions. With the right providers you can also use LINQ to query XML and databases - with your LINQ expressions being 'compiled' to SQL or an appropriate query language.

LINQ expression trees represent query expressions. In IronPython 2.0 Beta 4 the DLR expression trees merged with LINQ expression trees and were moved into the same namespace.

Unfortunately this caused name collisions all over the shop and made it virtually impossible to use IronPython or the DLR in projects that also used .NET 3.5 (particularly for ASP.NET projects). To resolve this problem the names have been moved again.

Harry Pierson explains the issues and the solutions:
The DLR Hosting blog summarises it more succintly:

"The recent beta release of the DLR allows the usage of LINQ and other CSharp 3.0 features in an application that hosts the DLR."

IronPython 2.0 B5 - New Hosting API

For those interested in embedding IronPython in .NET applications there were two significant changes in IronPython 2 Beta 5. As this is the last beta before the release candidate, integrating this release should be the last changes you need to make.

The first change is that a significant portion of the hosting API has changed - and for some (but not all) use cases got a lot simpler.

Embedding Dynamic Language Runtime engines (what we are discussing here is the DLR hosting API) uses the App.Config file to configure the languages they intend to use. This part is probably more complicated than before. The DLR Hosting blog has a self-contained Visual Studio 2008 sample demonstrating how it works:
For languages like IronPython and IronRuby, convenience classes have been added that make hosting simpler. For IronPython the class is called Python. You can create a ScriptRuntime (one of the core hosting classes) without using the config system.

The DLR Hosting blog shows the basics:
Srivatsn (an IronPython tester) also has a blog on the subject - showing more of the convenience methods on the Python class. These include easy ScriptEngine creation and easy access to the builtin, sys and clr modules for an IronPython engine:
Srivatsn demonstrates pulling out builtin Python functions and calling them from C# - a useful technique for using dynamically created Python objects from other .NET languages.

Sunday, September 21, 2008

Custom Fixed Size ListBox Items in IronPython in 30 Seconds

Ross was one of the developers who attended our IronPython tutorial at PyCon UK. Prior to the tutorial he was experimenting with Windows Forms. This recipe is a snippet of code for drawing fixed height custom listbox items (by handling the 'DrawItem' event):
From another blog entry, he comments on working with Windows Forms from IronPython:

"One thing I did notice whilst playing with IronPython and System.Windows.Forms was how relevant any S.W.F. experience you already have is likely to be. Yes, you’ll be writing a lot less code, but apart from the fact you’re using a much nicer language, the way that the UI works is obviously the same - which for some reason wasn’t as obvious to me as it should have been."

REMLOG and the Dynamic Languages Braintrust

Dave Remy is the uber-commander-in-chief of the dynamic languages at Microsoft, and he blogs.

If you've ever wondered what the dynamic language team members look like, Dave has some photos of them from a lunch meeting with the 'brain-trust':
He also got together with Mike Vincent, who is "on the Board of Directors of INETA (International .NET Association) which works to coordinate a huge community of .NET user groups".

INETA is in touch with a large community of .NET developers:

"It appears INETA has great momentum, with greater than 250 active user groups and over 100,000 active developers in North America, and a reach of approximately 1.2 million developers world-wide."
"One question we asked was how important Mike saw Visual Studio Integration for the Iron languages. We get feedback at times that it is more important to have a lightweight, quick to bring up, quick to close down, editor for script editing than full VS integration. Others tell us, make sure that we integrate well with VS now since this is their primary code editing tool. Mike’s response was that VS integration is “a big deal” for adoption by the mainstream .NET developer and consequently a must have."

Saturday, September 20, 2008

Embedding Boo and IronPython

Nahum Dotan has been trying to evaluate which of Boo and IronPython are more suitable for embedding. (Boo is a statically typed .NET / Mono programming language with duck typing and a Python inspired syntax.)

"In short, I didn’t come to a conclusion.

But I did have some fun. I played with the thought that using python’s native dictionary initialization syntax would be nice as a configuration file syntax (e.g. ini files).

So I whipped a sample project that would embed both Boo and IronPython and looked at the differences with usage. So far I’m liking IronPython better.

This example is ridiculously simple, but you can go ahead and tinker with the engines, its a good timekiller."

IronPython Bugs

No, this entry isn't about bugs in IronPython - it's about two blog entries by Dave Fugate (an IronPython tester) on the processes around fixing bugs in IronPython.

The IronPython issue tracker is hosted on Codeplex. The tracker is triaged weekly to review new bugs and Dave explains the different factors involved in assigning bugs to releases.
In his next entry, Dave explains the best way to get your bug report noticed and fixed: Getting Your IronPython Bugs Fixed Quickly
  • Use the bug template when reporting on CodePlex
  • Emphasize if the bug blocks an application
  • Email the list as well
  • Provide the simplest repro possible

Friday, September 19, 2008

A Time Tracking Tool, IronPython Learnings & Google Authentication

Joseph Jude has been learning IronPython. He's created a time tracking tool, which tracks how long you use different applications on your PC. He's also posted a blog entry about learning IronPython.

This entry covers the tools he uses and some of the problems (with solutions) that he encountered:
He has also made his 'time tracking tool' available for download:
While I was waiting for Django 1.0 to be released, I wanted to quickly learn to develop desktop applications. I preferred it to be on Python so that I can continue to learn the language. I did an evaluation of different options and settled on IronPython.

As a consultant, there is always a need to submit timesheets. By the end of the day/week, it is difficult to remember the tasks done during that time-span (day/week). If somehow a tool can capture applications that were worked on, then it will help.

This application polls the active window at an interval of 5 seconds and captures the application details (application name and the application title) and the time spent on each of these tasks. It can be minimized into systray so that it can continue to capture details without any disturbance (first icon). One can download the details on the grid as a csv file too.

In his very latest blog entry Joseph has been exploring doing google account authentication for desktop applications. He uses the Google AppEngine to do the authentication and shows code for communicate with the web app (a Django app) from both 'normal Python' and IronPython (using the .NET web libraries):

IronPython Desktop Application will pass userid, password to AppEngine Application, which in turn will validate with Google Accounts Authentication service. If authenticated, AppEngine application will proceed; else it will pass the error back to the desktop application.

Simple IronPython Example Using XML, Oracle and SQL Server

From the "Head Above The Clouds Blog":

This is an IronPython example of using .NET classes to load a XML document, query it with a simple XPath expression, and then using the results to transfer data from an Oracle to a SQL Server database.

Thursday, September 18, 2008

Ironclad 0.6 Released and numpy in Resolver One

Since I last updated this blog (yes I've fallen behind in the last couple of weeks - I'll catch up soon) a lot has happened with Resolver One.

Resolver One is a spreadsheet development environment created by Resolver Systems and built on IronPython. Version 1.2 was released not long ago.

This includes several major new features, including one called 'RunWorkbook' that greatly helps with our goal of making spreadsheet system design modular, maintainable and resusable.

Part of our plan for Resolver One includes being able to use numpy (a C extension). At PyCon UK William Reade demonstrated working with numpy arrays containing one million items from inside Resolver One. This was using an experimental version of Resolver One ported to run on IronPython 2, along with Ironclad - our open source project that allows you to use Python C extensions from IronPython.

The Resolver Systems blog includes links to the slides for Giles Thomas's PyCon UK talk and William's lightning talk showing numpy with Resolver One.
William is the core developer for Ironclad and he has just announced the release of Ironclad 0.6. It is now based on IronPython 2 Beta 5 and a useful subset of numpy 1.2 RC 1 is importable and usable.

From the announcement by William:

I'm very happy to announce the release of Ironclad v0.6, which targets the recent release of IronPython 2.0b5. It's now possible to import the current release candidate for NumPy 1.2, and some of it actually works. Yay!

If you're interested, please download it and try it out; I'm very keen to hear everyone's experiences, both with NumPy and with other C extensions. I'm fully prepared for the fact that most of these will take the form of extremely short narratives along the lines of "I couldn't import foo", or "I did X, and then Y, and then it gave me the following error", but the project is now mature enough that it's *possible* that someone will say "I imported bar, and it kinda worked". That would, of course, make me tremendously happy, so I feel it's worth a try. In the absence of outside feedback, I will continue to work on NumPy; I get the impression that matrices would be widely useful, so they're my next target.

If you're interested in using numpy from IronPython, then download the latest release and tell us which bits don't work!

IronPython 2.0 Beta 5 Released

IronPython 2 Beta 5 has just been released. IronPython 2 is an implementation of Python for Mono and the .NET framework and is built on top of the Dynamic Language Runtime.

IronPython 2 Beta 5 is intended to be the last beta before the release of IronPython 2 final (although there will probably be at least one release candidate) - so if you want bugs fixing now is the time to test and report them!
This release includes fairly major changes to the DLR hosting API, including a new convenience class 'IronPython.Hosting.Python' that makes a lot of the common patterns for embedding IronPython a lot simpler.

It also includes some namespace moves to avoid clashing with .NET 3.5.

Over 100 codeplex work items (plus other bugs reported internally at Microsoft) were closed between beta 4 and beta 5. As this number includes items closed as 'duplicate' or 'by design' the actual number of bugs fixed is not reported... For the full list see the release notes, and if you're embedding IronPython then get ready to change your code again - but hopefully for the last time for a while.

Wednesday, September 10, 2008

DLR Hosting Spec

The DLR Hosting API blog has the details on the latest version of the DLR Hosting Specification that is now available. Since IronPython 2.0 Beta 4 (the most recent released version) the mechanism for initializing engines for hosted Dynamic Language Runtime languages has changed.

At the same time a new convenience class has been introduced making it much simpler to work with an embedded IronPython engine.

The new spec gives all the details and the blog entry demonstrates initializing an 'arbitrary' language through XML configuration.
Although the new specifications makes for simple deployment and configuration of systems using a single embedded language it may make them 'interesting' for situations where multiple DLR languages need to be used together.

Tuesday, September 09, 2008

Reports on IronPython and Dynamic Languages from Recent Conferences

Several reports on talks on IronPython and dynamic languages from the Microsoft TechEd conference (New Zealand) and Microsoft Technology Summit.

Scott Yang liked harry Pierson't talk at TechEd:

The final show today was the highlight — “Pumping Iron: Dynamic Languages on .NET” where Harry Pierson talked about the benefit of dynamic typing languages and why they are useful to .NET users. Great presentation, and great arguments on why the lack of compile time checking is NOT really an issue. IronPython was used in the code example, which is something I am a bit familiar with.

Jamie Penney's notes on the same talk:

WEB305: Pumping Iron: Dynamic Languages on .Net - Harry Pierson

  • Tradeoff between Type Safety and Flexibility
    • Rails ActiveRecord example - AR adds the column names of a table as properties on the model class at run time.
  • Real products are being shipped on IronPython - Resolver One
  • Dynamic languages are very productive - good for initial work on greenfield projects.
  • Dynamic languages are not as fast as Static languages, so optimise by replacing slow parts of Iron(Ruby/Python) with C#. This is easy in the Iron* languages.
  • Dynamic Languages are easy to teach and learn.
    • Short on Ceremony - You don't have to add extra stuff like package management or class creation to python if you don't want to.
  • Formatting and whitespace matters. All Python code looks the same, so it is easy to start working with someone else's code.
  • Dynamic languages are powerful.
    • AOP is easy in Python - it is possible to pass functions around as they are first level citizens, or you can use decorators to wrap functions.
    • You can create new types at runtime - example given was an XML to Python loader, which created Python objects from any given XML document.
  • Iron* languages are first class .Net citizens.
    • Interop with other .Net code. Easy to use C# or VB.Net code from Iron* languages, but it is harder to go the other way. Standard .Net assemblies just work in Iron.
  • Iron languages are embeddable by using the DLR.
  • Microsoft are working on integration with Visual Studio currently, due in 2009.
  • IronRuby and IronPython are both true Open Source.

A report on dynamic languages from day 2 of the Microsoft Technology Summit. This is from a talk given by John Lam:

Dynamic Languages @ Microsoft
John Lam, Senior Program Manager for Visual Studio Managed Languages discussed the Dynamic Language Runtime. In response to his own rhetorical question asking why Microsoft would support dynamic and open source languages on the .NET runtime, he listed the following reasons:

  • increased opportunity to get Microsoft technology used
  • clear trend to build stuff on OSS
  • developers want freedom to create stuff
  • developers want freedom to see the source code

The Microsoft Permissive License got changed to Microsoft Public License(MSPL), and got OSI approval.

The Dynamic Language Runtime(DLR) was refactored from the IronPython implementation. Common code and services that were needed for dynamic languages was extracted into a reusable framework.

Because the DLR is distributed as MSPL, anyone can port to other platforms. So assemblies can run on Mono without changes.

Microsoft is hoping to have Rails running on the DLR by RailsConf 08. John demoed Django today, but acknowledged having to make a few changes to the Django source to do so. He also admitted that both IronRuby and IronPython have performance issues right now.

IronPython Tutorial and Twatter on Mono

It's only a few days until PyCon UK. Christian, Menno and I have been preparing the IronPython tutorial and there is new information on the wiki about what you will need if you are attending.
We will support IronPython on Linux, Mac (both via Mono) or Windows - and you get to take your pick of four different databases.

During the tutorial we will work through creating a windows forms based Twitter client called Twatter. There are more details on my blog, along with a screenshot of it running on the Mac and a screenshot of the example application for the early chapters of IronPython in Action.
Since I wrote that entry Christian has done some more work, and Twatter now fetches images of tweeters. Here's a screenshot of it running with IronPython 2 and Mono 2.0 preview 3 on the Mac:

Thursday, September 04, 2008

Polyglot Python

Adam Wolf decides to learn a new programming language - and in attempt to thin out the number of possibilities he limits the field to those that he can use for both desktop application development and with Silverlight. Naturally this brings him to IronPython.
"The winner is IronPython, a dynamic language used in conjunction with the new .Net Dynamic Language Runtime. Python was created in the 1980s by Guido van Rossum, who is now working at Google. The Python language is a wrist friendly language due to its terse syntax and no need for the normal text enclosures like C# and VB.Net. The language comes with the “batteries included” and this refers to the numerous libraries that come with the language, which will enable you to write almost any type of software. The IronPython implementation on the .Net platform has full access to these standard Python libraries as well as the full .Net Framework."

As an added bonus he decides to learn by reading the early access version of IronPython in Action. (Which is now heading into production and should be available in dead tree version in November.)

"I have started learning Python from the Manning’s early access program from the book “IronPython in Action”. The early access program gives you access to the book as the authors and editors are working on future chapters. In the first part of the book, the authors build a Windows application using an iterative development style and design patterns to teach the reader the Python language. I really enjoy this approach because I can read and try the concepts in a real application development scenario."

IronPython at PyWorks and PyCon UK Conferences

The PyWorks 2008 conference schedule is now up. This is a new conference, held in Atlanta November 12th-14th, by the same people who bring us the Python Magazine. I'll be speaking at PyWorks on IronPython: Python on .NET and in your Browser.
I'll also be at the UK Python conference (along with most of the Resolver Systems developers) in Birmingham September 12-14th. Three of us (Christian Muirhead, Menno Smits and I) will be giving a half day tutorial on Developing with IronPython (on the Friday morning). In this blog entry I talk about the sample application we'll be building together in the tutorial (come with IDE and ready to code) - plus a call for volunteers for the conference itself:
"The tutorial is based around a simple Twitter client, which Menno has named Twatter! We've been testing Twatter on Windows, Linux and the Mac (it doesn't look bad on the Mac)."

"At each step we will be introducing a new topic and explain the principles. We'll give the attendees the skeleton of the code and then assist you to add new functionality. It is a very simple application, but we will manage to cover topics including (all using .NET APIs from IronPython):"
  • Windows Forms
  • Databases
  • Web services and network access
  • Handling XML
  • Threading
UPDATE: Ross is one of the folks coming to the IronPython tutorial and he has blogged about preparing. Hopefully we will be able to answer his "why use IronPython?" question.