Saturday, July 17, 2010

IronPython 2.7 Alpha 1 release (and license change)

The IronPython team have just announced the first release of IronPython 2.7, an alpha 1 release. This targets compatibility with Python 2.7, and comes with interesting news about the license that IronPython is released under. There is also more of Python's standard library included; specifically two more C extension libraries previously unavailable with IronPython.

The next release of IronPython will probably be a bugfix release of IronPython 2.6: 2.6.2. Once 2.7 is complete the IronPython team will move onto IronPython 3, targeting compatibility with 3.2 - which is likely to be the current version of Python 3 when IronPython 3 is completed.

We’re pleased to announce the Alpha release of IronPython 2.7 which can be downloaded at  This is a major new version of IronPython with a number of significant updates.  Because this is an Alpha release it is not yet feature complete nor fully compatible with CPython 2.7.  Changes thus far include:
  • Updates the language to be compatible with CPython 2.7
  • Adds integrated Visual Studio support (IronPython Tools for Visual Studio)
  • Extends CPython 2.7’s documentation with useful information pertaining to IronPython
  • Adds the mmap and signal modules
  • Includes a number of performance updates and bug fixes
  • Switches the license to Apache License, Version 2.0
  • Requires .NET 4.0 and Silverlight 4.0
Python 2.7 includes a number of features backported from the Python 3.0 series.  This release implements the new builtin _io module, includes dictionary and set comprehensions, set literals, supports multiple context managers in the with statement, and adds several new functions to the itertools methods, and auto indexing for the new string formatting.  There are also numerous updates to the standard library such as ordered dictionaries and the new argparse module.
This release also includes a “IronPython Tools for Visual Studio” option within the IronPython installer.  This enables one install to get both IronPython and IronPython Visual Studio support assuming you have an existing installation of Visual Studio 2010.  This version of IronPython Tools includes a number of bug fixes as well as the start of improved WPF designer support.  We discovered very late that the WPF designer support may crash VS when not running under the debugger.  If you’d like to try the WPF designer support and give us feedback, just launch another Visual Studio instance and attach to the instance in which you are using the WPF designer support.
We’ve also updated the IronPython installer to include documentation based upon the CPython documentation.  This new .chm file includes documentation on the Python language and standard library.  It’s been extended from the normal Python documentation to include IronPython specific topics such as the DLR hosting APIs and extending IronPython from statically typed .NET languages. 
We flushed out more support for missing built-in modules which CPython includes.  This release includes the mmap and signal modules bringing better support for interoperating with unmanaged code.
As usual there are a number of bug fixes and performance improvements.  This release includes major performance improvements in cPickle, the sum built-in function, and includes support for fast exceptions which do not use the .NET exception mechanism.  There have also been improvements to significantly reduce memory usage of the IronPython ASTs.  One of the end results of these numerous improvements is that IronPython’s startup time has decreased by 10% when compared to IronPython 2.6.1.
Finally, with this release we have changed the license from the Microsoft Public License to the Apache License, Version 2.0.  We’ve made this change based upon continual feedback and questions from the community.  The Apache License will be more familiar while remaining an open source license.
- The IronPython Team

Saturday, July 10, 2010

NumPy and SciPy for IronPython and .NET

The genius of IronPython is that it provides great integration with .NET libraries. The cost of this is that you no longer have access to Python extensions implemented in C unless the IronPython team, or a third party, has created an equivalent version in C# or wrapping an existing .NET library.

One very powerful and widely used set of Python extensions come in the form of NumPy and SciPy. This is a particular problem for those interested in IronPython as there is nothing of equivalent functionality and quality in the .NET world.

There is an existing way of accessing Python C extensions from IronPython in the form of Ironclad. Ironclad was specifically designed to work with NumPy, and it works astonishingly well, but it can never be as good as a native library.

Microsoft are obviously very interested in NumPy as they have just announced an interesting partnership with Enthought, a company who are active in the Scientific Python community. The partnership is specifically to bring a .NET implementation of NumPy to IronPython. The announcement was made at the SciPy 2010 conference.

Enthought, Inc., a leading Python and Scientific Computing technology provider announces plans to extend the SciPy and NumPy libraries to IronPython and the .Net Framework. Availability of these libraries on .Net provides advanced technical computing tools to the flexible, fully-featured Microsoft Windows software environment.
"These libraries are fundamental building blocks for technical computing applications, and we are very excited to see them become available to IronPython and the .Net community," said Shahrokh Mortazavi, Architect in Microsoft's High Performance Computing Group.
"It is exciting to witness the impact SciPy and NumPy have had on the technical computing community over the last decade. We are excited to unleash the power of these tools to a whole new group of users on the .Net platform," said Travis Oliphant, president of Enthought, addressing the attendees of the SciPy 2010 conference in Austin, TX. 
SciPy and NumPy are a suite of high-performance statistical and numerical tools for the Python programming language. They are used primarily for rapid data processing and analysis in scientific and quantitative applications.  Enthought principals, Eric Jones and Travis Oliphant, were the initial authors of SciPy, and Travis was the primary author of NumPy.   Both tools are actively maintained and enhanced by a large open-source community, and have been widely adopted by leading researchers, institutions, and commercial enterprises worldwide.  
The .Net Framework consists of a Common Language Runtime (CLR) abstraction layer over the operating system, pre-built class libraries for low-level programming tasks, and a range of specialized development frameworks and technologies that enable reusable custom applications. The collaborative effort announced today will enable existing Python applications utilizing NumPy and SciPy to run un-modified on IronPython and to take advantage of the high-performance Just-In-Time (JIT) compiler technology built into the .Net framework.  

IronPython Tools for Visual Studio CTP3

At PyCon this year Dino Veihland announced IronPython Tools for Visual Studio, an extension to Visual Studio 2010 for working with IronPython. It features Python syntax highlighting, awesome auto-complete (intellisense) and a host of other features for working with IronPython code in Visual Studio. It can be used with the free Visual Studio shell and doesn't require you to own a full copy of Visual Studio.

The third CTP (Community Technology Preview) has been made available for download.

We are happy to announce a minor update to the IronPython Tools for Visual Studio.  IronPython Tools for Visual Studio (IPyTools) is a set of extensions available for Visual Studio 2010 which supports development of IronPython applications.  This release is our 3rd Community Technical Preview (CTP) and builds upon the previous two releases.  The release is a minor update which includes bug fixes and a number of small features.  You can download the latest release at
There is also one major change in that the project system is no longer based upon the files which live on disk.  Instead we now follow the normal VS project model.  This means files must be explicitly added to the project and files which you don’t want in the project won’t automatically show up.  We made this change based upon feedback from people using the tool and think it will make it more familiar for normal Visual Studio users.  Despite this change there is still support for an “implicit” project when working without a project.
Like the previous release this release includes support for Intellisense including member completion, signature help, find all references, and goto definition.  It enables quick browsing of your code using the object browser and the editor navigation bar.  It has an interactive (REPL) window that enables the development of applications in an interactive way.  IPyTools supports lightweight development without a project as well as working with project files in the tradition of Visual Studio .  Opening a .py file causes IronPython Tools to model the code in the containing directory as an implicit project for Intellisense features.   There are project templates for console, WPF, WinForms, and Silverlight applications.  WPF applications support drag-and-drop UI development.  Debugging of Python applications works just like you debug other languages in Visual Studio.
We are still working on our final licensing terms for IronPython Tools, and as such this release is licensed under a temporary limited use license.  While we weren’t able to finalize this for this release we expect to have this finalized for the next release.
The full list of changes includes a number of bug fixes:
  • Interactive window now respects VS color settings
  • Fixed default settings for insert tabs, enter completing options, list of characters to complete to
  • Fixed auto-indent inserting extra tabs on a blank line
  • Enables usage of VS common settings for smart indentation and tabs and respects those options.
  • Escape in REPL cancels both the intellisense session and the current input
  • REPL: When a completion item is focused but not selective enter should not complete it
  • REPL: We should respect the various intellisense completion options
  • REPL: We should be using IronPython’s auto intending
  • Fix repl not respecting smart up/down on startup if the window was set to be open
  • REPL: Don’t allow history if the current command is still running – instead navigate the buffer
  • REPL: Enable syntax highlighting even if a command throws an exception
  • REPL:     Remove trailing new lines from REPL history so we go back to the last line of input
  • REPL: When pasting ensure there’s a new line
  • REPL: Auto indent should delete selected lines when pressing enter
There are also a few new features:
  • New Fill Comment Paragraph feature
  • Implemented auto-dedent so it will backspace # of tabs
  • Support for disabling intellisense via normal VS mechanism
  • Support for hiding “advanced” members in intellisense (currently defined as __abc__ members)
There is one major change:
  • Removes directory based projects in favor of normal VS style projects
- The IronPython Team

Saturday, June 19, 2010

Iron Web Analyzer and Scripting TIBCO Spotfire

IronPython is a great language for application development, but also provides a readymade scripting engine for adding to .NET applications.

A fresh example of the first, an application written in IronPython, is the open source "Iron Web Analyzer" (Windows only I believe):

Iron Web Analyzer is an open source application for web masters to analyze web sites content. Iron Web analyzer employ Iron Python to analyze server responed data. Iron Web Analyzer downloads data from server and dispatches them between Iron Python Analyzer installed on application and collect analyze results produced by Python applications.
An example of the second use case for IronPython is the recently announced support for IronPython scripting in TIBCO Spotfire:
In TIBCO Spotfire version 3.1, TIBCO introduces the concept of Script Controls. Scripts Controls provide the ability to add IronPython scripts into a Text Area inside a Spotfire Analysis file. The script has access to the full Client API (from the SDK), and its goal is to perform common automation tasks.

SharpDevelop 4 and unittest2

Two weeks ago I reported on the latest news from SharpDevelop, the integration of unittest into SharpDevelop 4 for testing with IronPython. In my report I suggested that supporting unittest2 would be even better and Matt Ward has risen to the challenge.

Matt's latest blog entry shows how to use unittest2 to run IronPython unit tests in the forthcoming SharpDevelop 4 IDE:

SharpDevelop 4 has been updated to support running IronPython unit tests that use the unittest2 library.
Make sure unittest2 is on the Python path before running the unit tests.
Out of the box SharpDevelop will actually use the unittest library's test runner. This seems to work however if you actually need to use the unittest2 test runner then you can modify the following two files in the folder: AddIns\AddIns\BackendBindings\PythonBinding\TestRunner.

Tuesday, June 15, 2010

IronPython at TechEd

TechEd 2010 has just finished, one of Microsoft's biggest developer conferences. Lisa Feigenbaum, who is program manager for the Visual Studio Languages Community, has posted a blog entry with links to all the Visual Studio Language & IDE Resources from TechEd North America 2010 (C#, VB, F#, IronPython, IronRuby).

Our own inestimable Dino Viehland, the IronPython workhorse and genius, was there and gave two presentations on IronPython:

Abstract: The Dynamic Language Runtime (DLR) brings the power of dynamic languages to Microsoft .NET. It provides the plumbing for IronPython and IronRuby, a shared language hosting API, and also enables interoperability with static languages like C# and Visual Basic. Come hear how you can leverage these technologies in your own applications, and learn why dynamic languages deserve a spot in your toolbox!
 Abstract: IronPython Tools for Visual Studio is an extension for Microsoft Visual Studio which provides Python programmers with a great development experience inside of Visual Studio. It supports all of the usual Visual Studio features such as editing including rich Intellisense, debugging, light weight Python projects, and participating in Visual Studio solutions. In addition to the usual Visual Studio features it also supports a REPL window for a lightweight development experience which Python developers are accustomed to. Come and see IronPython Tools in action and see some new and exciting ways to work in Visual Studio.

Wednesday, June 09, 2010

Finding lyrics and converting Word files to text

Two fun, and possibly useful, recipes using IronPython have surfaced in blog entries recently.

This first recipe is from Mark Bloodworth, a Microsoft architect with a fondness for Python and IronPython:
I was looking some lyrics up online this week, so I wondered how hard to would be to write a simple application to find lyrics to your favourite song.  Or to your least favourite song.  Or, in fact, to any arbritrary song.  Via programmableweb, I found the API to lyricsfly, which looked easy to use.  Another IronPython console app beckoned.
Keeping it simple, I decided to use optparse to parse the command-line options and urllib to make the http calls.  This way the program can be called with the user_id that lyricsfly requires (head to their website and you can get a temporary weekly key to try this out) along with the artist name and song title.  What I decided not to do at this stage was to process the resulting XML.  Or handle any errors.  Or handle cases where the user_id, artist or title is not supplied.  But, although rudimentary, it works. ...
While SaveAs method in Word has Encoding parameter, it wasn’t quite clear, how would I specify it from pywin32.
So, my next attempt was to use IronPython, since it has native .NET interface with Office. The biggest advantage of this approach was the fact that you can do dir() on all objects and methods in IronPython shell.
After some googling on encodings, and IronPython Word scripting, here is the script I came up with. ...

Wednesday, June 02, 2010

Unit Testing with IronPython in SharpDevelop 4

Microsoft may have finally pulled out their collective thumbs and started to support IronPython in Visual Studio, but SharpDevelop has always led the way as far back as 2007 in supporting IronPython.

SharpDevelop 4 is now under development and integrates with the unittest module to support unit testing with IronPython. This feature requires Python 2.6 to be installed, and IronPython debugging is not currently working with SharpDevelop 4, but it looks like it will a great release.

Matt Ward gives us the details in his latest entry on the SharpDevelop community blog:

SharpDevelop 4 has been updated to support unit testing with IronPython.
First you will need to install Python 2.6. SharpDevelop uses the standard Python unit test library ( to run the unit tests.
Once the project reference is added the unit tests can be run in the normal way by right clicking in the Unit Tests window and selecting Run tests. You can run all the tests in a project, all tests in a class or a single test method.
The output generated when running the unit tests is shown in the Output window.
Test failures are displayed in the Errors window. Clicking an error will open the corresponding code in the editor.

Of course support for unittest2 would be even better... 

Tuesday, May 25, 2010

A Good Mix 36: Jim Hugunin, Selenium Two, Embedding IronPython & IronPython with Expression Blend

Another collection of IronPython and DLR related articles from recent weeks.

Jim Hugunin is a bit of a Python veteran. As well as being the creator of two implementations of Python (Jython and IronPython), he also started the Numpy project (back when it was called Numeric). Not long ago he was swallowed by Microsoft, who also took on the development of IronPython and turning it into the Dynamic Language Runtime.

In this video interview Jim explains not only how he got involved in Python, but also what he has been up to recently.
One of the ways that .NET helps you separate your visual design from your application logic is through XAML; an XML based declarative language that can be used with both Windows Presentation Foundation (WPF) and Silverlight.

Naturally there are design tools that will generate XAML. Visual Studio is one of them, but the best one is Expression Blend. XAML has features that make it particularly suited for integration with statically typed languages (statically binding events to your code in your XAML for example), but it can still be used with IronPython - slurping up the XAML dynamically at runtime (including generating or transforming XAML) with the XamlReader.

Simon Segal has been looking at how he can use both Expression Blend and Visual Studio with his IronPython projects:
Finally I decided to synchronize two separate .XAML files in each of the two different projects, so the challenge was to find the most unobtrusive way of working in both IDE’s and easily syncing the the .XAML files after edits had been made. Given that one of the IDE’s was running a dynamic language with a REPL built in, I thought it shouldn’t prove too difficult.
Like I said its far from a perfect solution and to be frank it’s somewhat annoying however my frustration is another thing altogether if I’m faced with doing all my layout and design in Visual Studio – so I will live with it for the moment. Hopefully the IronPython team and or the Expression Blend Team can find a solution that flows changes through more seamlessly in the short term and the perhaps in the long term allow us to open IronPython and IronRuby projects in Blend.
By the way if your wondering about the codename of the project that drove this adventure (PONGO) – the answer is yes if you guessed that it’s something that revolves around IronPython and MongoDB and I will be blogging about that more in the coming weeks.

Selenium is probably the best known / most widely used web testing tools and it supports a host of different languages. At Resolver Systems we've used the .NET Remote Control for Selenium from IronPython for quite a while. This article is a tutorial on using Selenium 2 with IronPython and Internet Exploder:
This tutorial is to show how to use the .NET Selenium 2 with dynamic languages that run on the .NET Common Language Runtime. This tutorial uses IronPython.
To complete this tutorial you will need to have IronPython installed and you will also need to download the .NET Bindings from Google Code
This tutorial will not be using the Remote Driver and it will be using the InternetExplorerDriver as this is the only complete browser at the moment that doesn't need to be built from the Repository.
Yes, over the years I've been making entries in this blog we've seen a whole host of blog entries showing examples of embedding IronPython in .NET applications, but it is always fun when another developer discovers just how easy it is:
A requirement I have in an app I am writing is to allow the administrator to set up formulas which can be calculated at runtime. The client app is completely disconnected from Enterprise Core Objects, it uses a (query/command)->response approach so I didn’t want to expose OCL on the client, I also didn’t want to use OCL because I didn’t want arbitrary browsing of the model.
So I have been looking at IronPython – and I like it! I’m not going to go into details of what this code does, I’m just going to paste it so that you may take a look. In short the requirement is for the Admin to be able to retrieve values from the DB by name and perform whatever logic they wish in order to return a decimal result.

Saturday, May 22, 2010

MonoDroid: IronPython on Android?

MonoTouch is a cross-compiler IDE and toolchain for the iPhone OS series. It allows you to write iPhone / iPod Touch / iPad applications with .NET languages like C# and take advantage of nice features of the .NET framework (actually Mono) like the extensive class libraries, proper garbage collection and so on.

Because of the rules against interpreters and code generators MonoTouch didn't include the System.Reflection.Emit apis that are needed for Dynamic Language Runtime languages like IronPython and IronRuby. Despite this restriction  MonoTouch was a victim of the controversial Section 3.3.1 of the iPhone developer agreement that requires iPhone apps to be written in objective-C, C or C++. (Modern developers who prefer the reliability of garbage collection based languages need not apply...)

Apple's main goal seems to be sticking two fingers up to Adobe and banning their Flash cross compiler, but other tools like MonoTouch are collateral damage. If there was ever any doubt about whether you could write iPhone apps in Python (Python and objective-C are both running fine on jailbroken iPhones) that question has been decisively answered. The Adobe Flash cross-compiler does introduce an intermediate layer between your application and the device - the UI won't look and feel native and using any new APIs introduced in OS updates will be dependent on Adobe updating the tool. This is the reason that has been cited as the motivating factor for section 3.3.1. Although MonoTouch has a "runtime" providing some of the .NET features you still compile directly against the iPhone OS APIs: your UI can be native and there is no intermediate layer. Despite section 3.3.1 MonoTouch is still allowed for companies distributing internal apps and not using the app store (something that became possible in a recent OS update), but it's use is now doubtful for general app creation.

Fortunately the iPhone isn't the only game in town, you may possibly have heard of the google mobile OS called Android. Novell, the folks behind Mono and MonoTouch, have been creating an equivalent tool for Android and Miguel de Icaza announced it in a recent blog entry:

We are hard at work on MonoDroid -- Mono for Android -- and we have created a survey that will help us prioritize our tooling story and our binding story.
Most interesting is their feature list:

  Here is what you can expect from Mono on Android:
  • C#-ified bindings to the Android APIs.
  • Full JIT compiler: this means full LINQ, dynamic, and support for the Dynamic Language Runtime (IronPython, IronRuby and others).
  • Linker tools to ship only the bits that you need from Mono.
  • Ahead-of-Time compilation on install: when you install a Monodroid application, you can have Mono precompile the code to avoid any startup performance hit from your application. 
So, it looks like it will "soon" be possible to write applications for Android using IronPython - great!

Monday, May 03, 2010

adodbapi 2.3.0 (the django version) released

Vernon Cole has announced the release of a new version of adodbapi, a Windows database driver that works with both CPython and IronPython.

  This version is all about django support.  There are two targets:
    A) MS SQL database connections for mainstream django.
    B) running django on IronPython
   Thanks to Adam Vandenberg for the django modifications.

A Python DB-API 2.0 module that makes it easy to use Microsoft ADO for connecting with databases and other data sources using either CPython or IronPython.
This version is highly refactored following the work of Adam Vandenberg, and also has all of the current user suggested patches. Both the Mercurial tree and the downloadable zip files are updated.  (There is no fancy installer, just copy the folder in your site-packages folder.) This has been tested using CPython 2.3, CPython 2.6, IronPython 2.6 (.NET 2) and IronPython 2.6(.NET 4), accessing .mdb, MS-SQL and MySQL databases.  There is a separate .zip for Python 3.1.

* 100% DB-API 2.0 compliant.
* Includes pyunit testcases that describe how to use the module. 
* Fully implemented in Python.
* Licensed under the LGPL license.
* Supports eGenix mxDateTime, Python 2.3 datetime module and Python time module.
* Supports multiple paramstyles: 'qmark' 'named' 'format'
Whats new in version 2.3.0    # note: breaking changes and default changes!
  This version is all about django support.  There are two targets:
    A) MS SQL database connections for mainstream django.
    B) running django on IronPython
   Thanks to Adam Vandenberg for the django modifications.
   The changes are:

1. the ado constants are moved into their own module: ado_consts
      This may break some old code, but Adam did it on his version and I like the improvement in readability.
      Also, you get better documentation of some results, like convertion of MS data type codes to strings:
       >>> ado_consts.adTypeNames[202]
       >>> ado_consts.adTypeNames[cursr.description[0][1]]
  ** deprecation warning: access to these constants as* will be removed in the future **

2. will now default to client-side cursors. To get the old default, use something like:
      adodbapi.adodbapi.defaultCursorLocation = ado_consts.adUseServer 
  ** change in default warning **

3. Added ability to change paramstyle on the connection or the cursor:  (An extension to the db api)
    Possible values for paramstyle are: 'qmark', 'named', 'format'. The default remains 'qmark'.
    (SQL language in '%s' format or ':namedParameter' format will be converted to '?' internally.)
    when 'named' format is used, the parameters must be in a dict, rather than a sequence.
       >>>c = adodbapi.connect('someConnectionString',timeout=30)
       >>>c.paramstyle = 'spam'
  ** new extension feature **

4. Added abality to change the default paramstyle for adodbapi: (for django)
    >>> import adodbapi as Database
    >>> Database.paramstyle = 'format'
 ** new extension feature **
Whats new in version 2.2.7
1. Does not automagically change to mx.DateTime when mx package is installed. (This by popular demand.)
   to get results in  mx.DateTime format, use:
      adodbapi.adodbapi.dateconverter =  adodbapi.adodbapi.mxDateTimeConverter
2. implements

Saturday, May 01, 2010

SQLite, zlib and XNA

Jeff Hardy has been at it again, and has just done releases of both IronPython.SQLite and IronPython.Zlib - ports of the Python zlib and pysqlite modules to IronPython.
IronPython.Zlib  implements the zlib module for IronPython using ComponentAce’s, which is a purely managed implementation of the zlib library. IronPython.Zlib is entirely managed code and works with both 32-bit and 64-bit IronPython. It passes all of the Python 2.6 zlib and gzip tests and most of the zipfile tests.
IronPython.SQLite is a port of pysqlite to IronPython using C#-SQLite, which, similar to, is a managed implementation of SQLite. Thus, IronPython.SQLite is also 100% managed code. It passes about 87% of the Python 2.6 sqlite3 tests; the remaining ones are mostly corner cases or rarely used functionality.
Carl Trachte also emailed me about a Japanese blog post on using XNA with IronPython. XNA is the Microsoft game creation framework that runs on the XBox 360 and Windows. 

To run the example code you'll at least need the Microsoft XNA Framework Redistributable installed.
This blog entry is almost entirely a translation of a C# XNA example to IronPython. The C# code is shown commented out alongside the IronPython equivalent. All it does it create a window with a cornflower blue background, but could be a useful introduction to programming XNA.

IronPython Tools for Visual Studio

Visual Studio is the Microsoft IDE for Windows and is virtually ubiquitous as a Windows development tool. Unfortunately Visual Studio has never had good support for languages like Python, which became more of a problem for Microsoft when they developed and released a distribution of Python themselves (IronPython).

Whilst there have been many good IDEs with IronPython support there has until now been lacking from Visual Studio - and adding support has been the highest voted Visual Studio feature request for some time.

Adding good support for a dynamic language to an IDE is very different from supporting statically typed languages. The internals of Visual Studio rely on the static type information for the intellisense, designers, refactoring and so on. However, the IronPython team themselves have come to the rescue and built IronPython integration into Visual Studio 2010:

We are happy to announce the first broadly available release of IronPython Tools for Visual Studio.  IronPython Tools for Visual Studio (IPyTools) is a set of extensions available for Visual Studio 2010 which supports development of IronPython applications.  This release is still an early Community Technical Preview (CTP) and builds upon the preview release that we gave exclusively to attendees of PyCon 2010.  The release has been updated to run on the final version of Visual Studio 2010 and includes many bug fixes, performance improvements, and new features.

This release includes support for Intellisense including member completion, signature help, find all references, and goto definition.  It enables quick browsing of your code using the object browser and the editor navigation bar.  It has an interactive (REPL) window that enables the development of applications in an interactive way.  IPyTools supports lightweight development without a project as well as working with project files in the tradition of Visual Studio .  Opening a .py file causes IronPython Tools to model the code in the containing directory as an implicit project for Intellisense features.   There are project templates for console, WPF, WinForms, and Silverlight applications.  WPF applications support drag-and-drop UI development.  Debugging of Python applications works just like you debug other languages in Visual Studio.

Changes in this release touch on all the major features of IpyTools.  This includes updates to the interactive window, intellisense, the editor, and solutions and projects.  We’ve also made other small tweaks to improve the development experience.

The interactive window is one key focus of IpyTools.  This release continues to flush out the feature set of the interactive window.  We’ve added a new command to send a snippet of code from the editor into the file context containing the module's code.  We’ve added options to control evaluation of partial expressions for live-object intellisense in the REPL.  We’ve updated the key bindings to for explicitly navigating history in addition to the smart behavior of the arrow keys.  Also, the interactive window now supports calls to raw_input() and input().  Finding text in the REPL works now,in addition to a number of other bugs fixed to improve the overall experience.

This release also has many updates to intellisense.  We’ve increased the customization options for intellisense so you can now commit completions using enter.    There is an option to show the intersection or union of applicable members when multiple types can flow through the code where you are using completion.  Related to this, None no longer is considered to be in the intersection of members.  We’ve improved the analysis engine so that it now understands generators, yield expressions, calls to send on a generator, improved analysis of generic method calls, improved tracking of types through calls to list.append/pop/extend/insert, added support for * and ** args, improved analysis of imports, and significantly improved the performance of the analysis engine.  We’ve also cleaned up the display of a number of tooltips including more consistent display of signature completion.  We also better track calls on types vs. calls on instances.  Finally reference tracking has been improved to include accessing methods (not just calls), tracking references to built-in functions, and added support for some protocol methods such as __getattr__.  In addition to this a number of bugs have been fixed.

We’ve also improved the editing experience in this latest release.  This includes support for new commands such as comment/uncomment selection, goto matching brace, support for auto indentation, and highlighting matching braces based upon the current caret location.   We’ve added finer control over the editor experience, adding support for disabling outlining on file open.  And there are a number of small cleanups such as improving goto definition, making goto definition center the target line on the screen, and fixing method outlining which was improperly collapsing in some cases.

Finally we’ve made some small improvements to the solution and project experience.  This includes fixing basic issues such as double clicking on image files now opens them in the VS image editor, project and solutions no longer prompt for saving if they haven’t been modified, and we now properly hide hidden files in the solution explorer.  We’ve also improved the experience when invalid values are entered into project settings.  For the Silverlight templates we’ve fixed the issue where Firefox would be launched when IE was the default browser, and we now search for an empty port when launching Chiron for web projects.

Altogether this represents a significant improvement over the PyCon release in quality and functionality.  But this is still an early preview and as such you may run into issues, and we are looking forward to your feedback both on issues you encounter and the overall feature set.  Please see the spec doc for our current and planned features and feel free to comment on any of the contents.

We are still working on our final licensing terms for IronPython Tools, and as such this release is licensed under a temporary limited use license.  We hope to have nailed down the final licensing terms for the next CTP release.

- The IronPython Team

Updated Dynamic Languages in Silverlight Page

Silverlight is the Microsoft browser plugin that, amongst other things, allows you to run Python and Ruby in the browser with full access to the browser DOM. This is all through the magic of the Dynamic Language Runtime. With either Silverlight or Moonlight installed, the simplest DLR-based application can be contained in a single HTML file:

    <script src="" type="text/javascript">

    <script type="text/ruby">
window.alert "Ruby in the browser!"
    <script type="text/python">
window.Alert("Python works too!")

The introduction page on the site has now been updated.

Writing Silverlight applications in Ruby, Python, and other DLR-based languages only requires a local web server, a text editor, and a browser which supports Silverlight on Windows or Mac OS, or Moonlight on Linux systems.
The page has full details of how to get started with using Python and Silverlight including several examples and example applications.

Supported browsers include IE, Safari, Firefox and Chrome.

Sunday, April 25, 2010

IronPython in PyCharm, a new Python IDE

PyCharm is a new Python IDE from the JetBrains team, still available only as an "early preview" (beta planned this summer). As well as the "usual features" for Python IDEs (debugger, syntax highlighting, projects and code navigation, code completion, testing and version control integration, etc) it has some nice features like django support, Python refactoring and support for IronPython.

Some of the details of the IronPython support are on the PyCharm blog:

IronPython support. It includes the possibility to generate Python stubs for .NET assemblies, but for performance reasons the generation isn’t performed on project opening and needs to be triggered manually (press Alt-Enter on an import statement).

This will allow for code-completion (intellisense) to work for IronPython code in the PyCharm IDE. 

A Good Mix 35: Visual Studio, WPF, a cross-platform Resolver One and IronJS (A DLR based Javascript)

Another collection of IronPython and DLR related articles from recent weeks.

This extension adds IronPython and IronRuby to PowerConsole  so that you can interact with Visual Studio in IronPython/IronRuby. Please be aware that this extension only provides a simple tool to explore and interact with VS itself. It does not aim to be a development experience for the included languages.

An IronPython GUI library compatible with the Python GUI library EasyGUI. As the name implies, it is built on the WPF GUI library (making it Windows only). Like EasyGUI it has a demo app when you run the file showing the different controls/widgets the library supports.

For more examples of how to use it visit the EasyGUI tutorial.

Resolver One is a programmable spreadsheet written in IronPython. As well as being extremely powerful Resolver One is the largest codebase of IronPython "in the wild". Unfortunately because of third party .NET components used for the user interface Resolver One runs on Windows only.

The third party grid imposes other limitations on Resolver One, so the development team have finally decided to replace it with a custom grid that they are writing from scratch in IronPython. As well as giving them more flexibility, this is the first step towards making Resolver One cross platform (through Mono). The screencast linked above show you their progress so far, you can also read a bit more about their adventures in this blog entry on text rendering with GDI and GDI+.
IronJS is an implementation of Javascript for the Dynamic Language Runtime. By being built on top of the DLR it should be possible for code and objects written in IronPython, IronRuby and IronJS to interoperate. IronJS is not written by Microsoft, but instead is the creation of Fredrik Holmström.

IronJS is not complete, but is not far off. For example it recently became capable of compiling jQuery. Performance is also pretty good:
All in all I’ve reached my performance goal with IronJS, now it’s time to finish the runtime to support all statements/expressions/built-ins from the ECMAScript 3 Spec, there will still be changes which affect the performance of the core runtime/compiler, but (hopefully) not by any large amounts

Sunday, April 18, 2010

IronPython y SharpDevelop, en español (IronPython and SharpDevelop in Spanish)

A guide to using IronPython with the SharpDevelop IDE translated into Spanish. SharpDevelop is a .NET IDE for Windows. Of all the major .NET IDEs it has the best support for IronPython.

Hola. En este post vamos a hablar un poco del hermano de Python (ó CPython) para la plataforma de desarrollo de Microsoft .NET, IronPython.
Como he comentado a lo largo de la vida de este blog, alguien que se quiera dedicar a esta bendita profesión no puede estar ajeno a las combulsiones que se originan en este mundo. Si alguien no se había enterado (que creo que no) Microsoft ha lanzado una nueva versión de su archiconocido Visual Studio, versión 2010, junto con la plataforma de desarrollo Framework .NET 4.0. Según parece en esta versión se le empieza a dar una mayor importancia a lenguajes dinámicos, como IronPython. Y es por ello que me he decicido a investigar este territorio, tan inóspito para mí. Y es que aprender nunca pasa de moda.
Decir que IronPython es un lenguaje creado por Microsoft, aunque no hay que pagar ningún tipo de licencia. IronPython es una implementación de CPython (ó Python) escrita en C#.
También he leído (que no probado) que IronPython funciona con la plataforma Mono.
IronPython está ligado a la plataforma .NET en la cual nos encontremos, dándole soporte en su versión 2, y ahora con más fuerza en la versión 4. No es objetivo de este post describir la historia ni características de IronPython en profundidad (¡para eso he puesto los links!)

Tuesday, April 13, 2010

IronPython 2.6.1 Released

There have been three "IronPython relevant" releases in the last twenty four hours with another one to come.
  • IronPython 2.6.1 (for .NET 2 and .NET 4)
  • .NET 4.0
  • Visual Studio 2010
The next release is Silverlight 4, which includes new features like out-of-browser support, new controls (a rich text editor component), web cam and printing support and lots more. For those who still aren't aware, Silverlight is a browser plugin that works with Windows and Mac OS X and in IE, Safari, Firefox and Chrome browsers. There is an official port from the Mono team, called Moonlight, that works with Linux and Firefox.

.NET 4.0 is the version of the .NET framework (and C# language) that includes support for the dynamic keyword - allowing for dynamic typing in C# and easier interoperation between C# and dynamic languages.

IronPython 2.6.1 is the latest stable release of IronPython. Despite being a minor point release there are some very nice improvements and new features. Headline features include faster importing and startup, bugfixes in ctypes, *much* better Python Unicode compatibility and ssl module compatibility:
We’re pleased to announce the final release of IronPython 2.6.1. This version of IronPython makes great strides in stability and compatibility, including a considerable number of targeted bugfixes. This is our largest servicing release to date, and with your help both before and during the RC phase, along with the simultaneous release of .NET 4.0, this has become a very exciting release for all of us.

The IronPython 2.6.1 RC included fixes for well over 50 bugs, large and small. Ctypes has had a number of significant updates, including union support, variant_bool, and wintypes. Another focus has been on sys.settrace, making debugging more reliable. For example, sys.settrace now returns the correct frame, supports tracing through modules, and no longer interferes with “import os”. Other notable fixes include thread-safe importing, and the missing error code in _winreg exception.

In addition, we’ve made a substantial improvement in import time. Not only does this reduce startup time, but it can speed up the importing of large, definition-heavy modules by up to 50%.

Since the RC, we have fixed numerous other issues, as well as adding CPython’s to our distribution. We’ve also made some major unicode-related changes in response to your feedback on the mailing list, changes that improve compatibility with certain third-party applications including Django. In particular, invoking unicode() or using unicode string formatting will now call __unicode__() first if it is present on the object. Finally, we’ve included a new code sample that shows how to use __clrtype__ to create custom CLR classes from IronPython. This sample is a sneak preview of what we expect will become a fully supported IronPython module, so we encourage anyone who is so inclined to try it out and let us know how it goes.
.NET 4.0 includes a new version of the Common Language Runtime and to use the new features you need to use a version of IronPython compiled against .NET 4. This is why IronPython for .NET 4 is a separate download. Surprisingly, this version of IronPython is much faster than IronPython for .NET 2. Dave Fugate blogs about this (and other improvements for working with IronPython under .NET 4):
Where exactly is this improvement coming from?  Well we don't know quite yet.  Our first bona fide .NET 2.0 SP1 versus .NET 4.0 IronPython perf suite run occurred less than two weeks ago!  An educated guess is that at least a small portion of this improvement stems from the fact that Microsoft.Scripting.Core.dll is actually part of the .NET 4.0 framework.  Any ways, you can see more of the performance characteristics of IronPython running under both these .NET releases here.

Monday, April 05, 2010

Professional IronPython

Professional IronPython is a new book on IronPython, published by Wrox and written by John Meuller (who has apparently written 73 books).

Create applications that are more responsive to user needs

IronPython should be an important part of your developer's toolbox and this book will quickly get you up and running with this powerful language. John Paul Mueller clearly shows how IronPython can help you create better desktop or web-based applications in less time and with fewer errors. Throughout the pages, you'll find techniques for extending IronPython and making it a more robust language. In addition, you'll follow advanced steps such as building an IronPython extension that directly accesses the Win32 API. And you'll enhance your skill set as you introduce IronPython into other environments such as Linux® and Mac OS® X.      

Professional IronPython is the third book on IronPython, with the first two being IronPython in Action and Pro IronPython. It will come as no surprise to hear that my personal recommendation is IronPython in Action...

Wednesday, March 31, 2010

SharpDevelop 3.2 RC1 - with support for IronPython 2.6.1 RC1

IronPython 2.6.1 will bring some nice performance improvements and some big Unicode compatibility improvements to IronPython 2.6.

The release candidate of SharpDevelop (Windows IDE with superlative support for IronPython) includes support for the IronPython 2.6.1 release candidate.

The first release candidate for SharpDevelop 3.2 comes with updated language support, fixes to various features (eg C# <-> VB.NET conversion), as well as improvements you have asked for in our forums.
The highlights:
  • IronRuby 1.0 RC2 support
  • IronPython 2.6.1 RC1 support
  • Microsoft F#, February 2010 CTP support
  • SHFB support
  • SDR: Absolute and relative filenames for images
  • SDR: Zoom in Report Viewer

Sunday, March 21, 2010

Python in the Browser, IronPython in Visual Studio 2010 and Other PyCon Talks

PyCon 2010 was great fun, and included several talks on or including IronPython.

This is Jimmy Schementi's write-up of his talk on using Python in the Browser, with links to the video and slides:
You, the Python developer, use Python because you want to, but in the browser you use JavaScript because you think you have to. With IronPython you can write browser code in Python. I’ll only begin to answer "what can the browser bring to Python?" and "what can Python bring to the browser?" in this short overview; examples will be very simple (with the exception of a few flashy ones) to make sure you can get started immediately.

The video of Dino Veihland's talk on the new integration of IronPython with Visual Studio 2010. The integration, which works standalone with the Visual Studio extensibility shell or integrated into VS 2010, is alpha quality - but has lots of nice features for IronPython development. It includes awesome type inferencing for intellisense in Python code.
A shorter video from Dino Veihland on the current state of IronPython, including a demo of the Visual Studio 2010 integration.
A talk by Holger Krekel on the various implementations of Python, and how execnet works with all of them:
CPython 2.5/2.6/3.1, Jython, IronPython, PyPy, StacklessPython, UnladenSwallow, Cython ... what do we make of all these cool interpreter projects and versions? Where does competition help and where does it hamper?
In this interactive talk I'll highlight the main strengths of each of the Python interpreters. Furthermore, I'll discuss ways to leverage Python interpreters in a co-operative way, discuss challenges, projects and issues ahead and also briefly highlight 'execnet', one my own projects for bridging (Any) Python to (Any) Python.
A talk by Maciek Fijalkowski (PyPy developer) on how to write programs that will run on multiple implementations of Python (or more specifically - how to avoid depending on implementation details of CPython without realising it).
This talk will cover basics about writing cross-interpreter python programs. What to do and most of all what not to do. This will help you if you want at some point in time to run program on for example Java platform or faster python interpreter, but also if you want to keep it running between CPython releases.

Catching up with Jeff Hardy and Django on IronPython

Jeff Hardy is an IronPython MVP and a Python community member who has invested a lot of time in getting standard Python libraries available for IronPython. Some of his recent work has been with both Django and the zlib module. It's been a while since we've reported on his work, so this post gets us up to date with what Jeff has been working on:

The zlib module is a C extension for Python. Because it is in the Python standard library it is used by many other libraries, like setuptools, making it an important part of the Python infrastructure. Unfortunately not all of the standard library C extensions have been ported to IronPython. The problem of C extensions is one of the major drawbacks of alternative implementations of Python; both Jython and PyPy have the same problem. Even if your code is 'pure-Python' it may not run on alternative implementations if it uses C extensions.

For IronPython one solution is to use Ironclad, an open source project created by Resolver Systems that allows you to use Python C extensions with IronPython. A better solution is for 'someone' to port the C extension to IronPython; and in the case of zlib that someone is Jeff Hardy. The latest version of IronPython.Zlib targets the IronPython 2.6 release.
One of the most popular Python frameworks these days is Django, the Python web framework. Unfortunately this doesn't run out-of-the-box on IronPython, largely because of differences in the way that IronPython handles Unicode (all strings are Unicode by default). There are some important changes in IronPython 2.6.1, due to be released shortly, that should fix a lot of the issues.

Jeff has been working on a 'port' of Django to IronPython; basically getting the tests running and applying patches where necessary. He has also written up some instructions on getting the test suite to run:
This guide will explain how to setup and attempt to run the Django test suite on IronPython. Once the test suite runs, it should be much easier to fill in the parts of Django that don't work properly.

Tuesday, March 16, 2010

Acceptance Testing .NET Applications using IronPython

This article, written by Jonathan Hartley, was originally published in the Python Magazine.

Unit tests demonstrate to developers that individual functions and classes work as expected. Acceptance tests are an orthogonal complement to this. They verify to everybody, including managers and clients, that features they understand and care about are completed and working correctly. They also prove that the system as a whole is correctly integrated and that no regressions have occurred. Resolver Systems is developing a .NET desktop spreadsheet application, Resolver One, for which we have accumulated an acceptance testing framework. This framework uses Python’s standard unittest module, and is executed using IronPython. While Resolver One is written in IronPython, this technique allows IronPython tests to interact with product code written in any .NET language. This article describes the principles of this IronPython acceptance testing framework, and demonstrates them by creating an acceptance test for a small sample C# GUI application.

Tuesday, March 09, 2010

IronPython in Action: Manning Deal of the Day

March 9th (that's tomorrow at the time of typing) IronPython in Action is the Manning deal of the day. This is a one day offer with a special discount.

You can get the discount by buying IronPython in Action from the Manning website and using the discount code dotd0310tw.

It isn't only IronPython in Action that is on offer, you can also get Quick Python by Vern Ceder.

Monday, January 04, 2010

Most Popular Articles of 2009

 In 2009 I made 312 posts on IronPython-URLs, a bit short of an average of one a day that it looked like I might manage earlier in the year.

According to google analytics there were more than 112 thousand page views to a total of 2042 pages on the blog. An average of over three hundred page views a day. Feedburner estimates that this blog has around eight hundred readers. Many of those will read the articles via RSS or Planet Python and rarely visit the website.

It's interesting to note that of the most popular articles in 2009 (most page views) several of them are to do with choice of IDE or using IronPython with Visual Studio. The question of which IDE to use with IronPython is still alive and well:
  1. New Sample: Writing a DLR Language in C# or IronPython  (May 2009, 1892 page views)
  2. IronPython in SharpDevelop 3.1 and Converting C# to IronPython  (May 2009, 1412 page views)
  3. C# Becomes a Dynamic Language...  (December 2008, 1164 page views)
  4. Python is the easiest language in which to do interesting things  (February 2009, 1150 page views)
  5. Python Support in Visual Studio  (June 2009, 1119 page views)
  6. Another IDE for IronPython? Eclipse and PyDev  (July 2009, 1077 page views)
  7. Davy's IronPython Editor  (January 2009, 1032 page views)
  8. Jeff Hardy: Django, Zlib and easy_install on IronPython (January 2009, 949 page views)
  9. Writing an IronPython Debugger  (March 2009, 816 page views)
  10. Running Python from C#  (September 2008, 789 page views)
My recent post Does Microsoft Take Dynamic Languages Seriously looks a bit at how much work it would be to get IronPython support in Visual Studio, and there have been a couple of interesting posts on this topic since. IDEs and IronPython is a topic that is likely to continue to be of interest in 2010 as well.