Tools and IDEs

Working with IronPython

IronPython 2.6 console in Eclipse / PyDev


This article is the third in a series of articles on developing with IronPython. The other articles are:

A much more complete introduction to developing with IronPython is my book: IronPython in Action.


A frequent question on the IronPython mailing list is "what IDE should I use with IronPython?". For many .NET developers the question is phrased slightly differently, "how do I use IronPython in Visual Studio?".

In this article we'll look at using IronPython in Visual Studio and some other popular IDEs, and we'll also be looking at some standard tools for working with IronPython.


At the time of writing the latest version of IronPython was 2.6 Beta 2. IronPython 2.6 includes new features that are particularly useful for tools like debuggers. In 2.6 Beta 2 these features are not complete but will improve in the final release. At that point some of the tools we're exploring here will switch to using them and will gain advanced features that we expect in modern development environments.

I'll update this article (as time permits) when these tools, or IronPython itself, develops.

IronPython Studio

Visual Studio doesn't ship with any IronPython support by default. The easiest way of getting IronPython support into Visual Studio is through IronPython Studio. IronPython Studio is an open source sample of using the Visual Studio Shell (VSx) to extend Visual Studio; more on that word 'sample' later.

You can either install it as extension of Visual Studio 2008 professional or as a standalone IDE. To install it into Visual Studio you need the Integrated setup download, which is an msi installer. This will be the version I demonstrate. To use it as a standalone IDE you need the Isolated setup installer and you need to install the Visual Studio 2008 Shell Isolated Mode Redistributable.

Once you have IronPython Studio installed, assuming you are using the version integrated with Visual Studio, you will see some extra options when you go to create a new project.

Creating a new project with IronPython Studio


After installing IronPython Studio none of the IronPython related features worked in Visual Studio 2010 Beta.

The options for creating new projects are:

  • Windows application (Windows Forms)
  • Console application
  • Class library
  • WPF application

Both Windows and WPF applications have designers with IronPython support. All of the projects compile to binaries which include the IronPython binaries. Here's the rub though; IronPython Studio is built with IronPython 1, and in fact uses a static compilation feature of IronPython 1 that isn't available in IronPython 2. IronPython 1 is ooooold...


IronPython Studio uses a feature of IronPython 1 called CodeDom support. This feature was always fragile and was removed altogether in IronPython 2. This means that a straight port of IronPython Studio to use IronPython 2 isn't possible.

Once you have created your projects you can add references and use the Windows Forms or WPF designers in the expected way. References you add don't appear as clr.AddReference calls but instead are compiled into the binaries that are produced when you build your project.

Unfortunately because of the way the designers create code from your Windows Forms or WPF creations you can't take your generated code and just run it with IronPython 2. The generated code needs several modifications (adding imports and manually adding references for starters). Making changes to generated code is bad as any further changes you make in the designer will then interfere with what you've done.

My preference for using Windows Forms and WPF designers with IronPython is to use the normal C# designers and produce classes and XAML that can then easily be used from IronPython, subclassing them to implement needed functionality in Python. The fact that using classes written (or generated) in C# is so easy from IronPython is one of its best qualities.

Whilst you're editing Python files you get syntax highlighting and a very limited form of intellisense; so limited that it doesn't even offer members on the .NET types. The intellisense only works with the builtin types and keywords. It does offer intellisense on your own Python classes within the file that they are defined in, but not on classes that you import from other modules even if they are part of the same project. You don't get auto-indent when creating methods (etc) which is considered a pretty basic IDE feature in the Python world.

The autocomplete is too aggressive, I often have to go back and correct what it has added (and on occasion it corrects my corrections). Actually I find this to be a general problem with Visual Studio but it is much worse with IronPython Studio where you don't have the type declarations to limit the range of options.

It is a nice trick to be able to compile binary applications from the IDE, but it is possible to do that with IronPython 2 using Pyc (or embedding the IronPython engine in a stub executable). The designers also proved unreliable for me in practise, crashing regularly. IronPython Studio seems to behave very much like a 'sample', a great example of extending Visual Studio but not a production ready IDE for regular use. Since its release there have been no updates to IronPython Studio nor any response to bug reports or corrections of errors in documentation.

Although I don't recommend using it for creating projects that are mainly Python, the syntax highlighting is nice when you are adding Python files to a mainly C# project.


Debugging IronPython code in Visual Studio with IronPython Studio

IronPython Studio allows you to debug IronPython code. The project has to be compilable and capable of running under IronPython 1 but you can set break points and inspect the local variables and the call stack and so on. Looking at Python objects is slightly odd as they are not standard .NET objects. Instead you find instance variables as Keys and values in the __dict__ member of objects.

The debugging experience is pretty impressive but its usefulness is severely limited by only working with IronPython 1.

Visual Studio

Debugging IronPython code in Visual Studio 2010

By default setting break points in Python code doesn't work, but you can call System.Diagnostics.Debugger.Break() which invokes the debugger. If you use a debug build of IronPython this dumps you into the DLR internals where it is possible to navigate your way around the code, but it is not ideal. If you don't use a debug build of IronPython then the debugger will simply stop on the line of code that invokes the IronPython engine and won't allow you into the Python code itself.


If you would like to see better IronPython integration in Visual Studio 2010 please vote for (and comment on) this Microsoft Connect feedback item: IronPython Integration in Visual Studio 2010.

Instead there are two ways to do it, both of which do allow you to set breakpoints in Python code and rely on running IronPython in debug mode and not requiring a debug build of IronPython.

The first way:

  1. In Visual Studio, click on "File->Open->Project/Solution" or press Ctl-Shift-O
  2. Select ipy.exe from wherever you put it
  3. Right click ipy.exe in Solution Explorer and select Properties
  4. In the Command Arguments box, type "-D" (to generate debug code) and the full path to the script you want to execute. If you want to drop into interactive mode after the script executes, also include a "-i"
  5. Open the script you specified in step 4 and place breakpoints as usual
  6. Run via Debug->Start Debugging or press F5

The second way is for when you are embedding the IronPython engine. You need to set the "Debug" flag in the options you create the engine with:

using System;
using System.Collections.Generic;
using IronPython;
using IronPython.Hosting;
using Microsoft.Scripting;
using Microsoft.Scripting.Runtime;

namespace Embedding2008
    class Program
        static void Main(string[] args)
            var options = new Dictionary<string, object>();
            options["Debug"] = ScriptingRuntimeHelpers.True;
            var engine = Python.CreateEngine(options);

The debug experience (look at locals and call stack) isn't as nice as with IronPython Studio but it works.

Debugging IronPython code in Visual Studio 2008, with the Python engine in debug mode


An alternative way of getting IronPython support into Visual Studio is through the ASP.NET Futures Dynamic Languages Support. The current version targets IronPython 2.6 Beta 1 and apparently gives a better Python development experience than with IronPython Studio.

Dave Fugate describes it as having "fewer features and fewer bugs".

Visual Studio SDK Experimental Hive

Another option for getting IronPython into Visual Studio is the Visual Studio SDK. This works with Visual Studio 2005 or 2008 but again needs Visual Studio professional rather than Visual Studio Express.

Once the SDK is installed you have the option of starting Visual Studio under the 'Experimental Hive'. This provides similar functionality to IronPython Studio including designer support and the ability to compile binaries. Like IronPython Studio it uses IronPython 1.


Visual Studio is the 400 pound gorilla in the world of Windows IDEs. It is a great shame that its IronPython support is so poor. IronPython Studio is not a production quality IDE and is awkward to use even when integrated into Visual Studio. For anything other than small Python projects using Visual Studio as your main Python IDE will be a painful experience. The IronPython team are aware of this and are working on changing the situation!

It isn't all bad news however. Debugging IronPython code in Visual Studio is possible, and IronPython Studio helps with this if you are able to use it. Using C# in IronPython projects is so simple that there is no need to have designers that directly generate IronPython code. In addition, although not suitable for large projects, if all you are doing is including small amounts of Python in a mainly C# project then you will probably find using IronPython Studio bearable.


SharpDevelop 3.1 has features supporting IronPython. SharpDevelop is an open source .NET IDE for Windows. An early version of SharpDevelop was forked by the Mono team and used as the basis for MonoDevelop, the cross platform Mono IDE.


MonoDevelop was forked from SharpDevelop long before the support for IronPython was added. Unfortunately there is little to no IronPython support in MonoDevelop.

SharpDevelop distinguishes itself from Visual Studio by the range of languages and external tools it supports. Features include:

  • C#, VB.NET, Boo, IronPython and F# language support
  • Integrated Debugger
  • Code Analysis (FxCop)
  • Unit Testing (NUnit)
  • Code Coverage (PartCover)
  • Profiler (Roadmap)
  • Integrated Subversion support (TortoiseSVN)
  • StyleCop addin
  • Setup projects (WiX)
  • MSBuild 3.5 integration
  • Documentation generation (Sandcastle, SHFB)
  • Reflector addin

If you start SharpDevelop and create a new project you will see the options to create a new Python project.

Creating a new IronPython project in SharpDevelop

Like IronPython Studio SharpDevelop 3.1 has a Windows Forms designer and can compile to binaries. Unlike IronPython Studio it uses IronPython 2.0 and not IronPython 1.

At the time of writing, before IronPython 2.6 final release, it wasn't possible to swap projects from using IronPython 2.0 to 2.6. Removing the references to IronPython from the Python project and then manually adding a reference to IronPython 2.6 causes a crash when you try to build the project, which is understandable as changes would be needed in SharpDevelop to support the changes in IronPython 2.6. However if you don't need SharpDevelop to compile your projects then it is perfectly possible to use SharpDevelop as an IDE for developing projects for a different version of IronPython. There is support for changing the version used for debugging, which we'll get to shortly.

Windows Forms designer for IronPython in SharpDevelop

The designer is a work in progress with some, relatively minor, limitations. When editing Python files you get syntax highlighting but there is no intellisense for Python at all, not even for builtin types or classes you build yourself. There is also no auto-indent or dedent at points when you would expect it, for example when you define a function or start a conditional.

When you build a Python project with SharpDevelop it compiles it to an executable, how cool is that! The compiled binary, or binaries if you have separate class libraries as part of the solution, still depend on IronPython so the four assemblies that are part of IronPython 2 live alongside the executable.

As an added bonus SharpDevelop includes a novel feature for working with IronPython; code conversion. The tools menu item has a 'Convert code to' allowing C# and VB.NET projects to be converted to IronPython.

Converting code to IronPython

The code conversion is limited to converting classes so it will not convert an arbitary piece of code that is not inside a class. Of necessity it can't be 100% reliable but it is especially useful for converting example code from MSDN, which still doesn't have IronPython examples.


SharpDevelop's debugger can debug IronPython code. In order to do this you need to ensure that 'Just my code' is checked (the default) and 'Step over code without symbols' is not checked (not the default) in the debugging section of the 'Tools -> Options' dialog.

Setting the options for debugging

You can set breakpoints in your Python code and the debugger is pretty good. I found I had to start the project from the 'Python -> Run' menu option and not from the toolbar icon for debugging to work. Like Visual Studio you have to hunt for the local variables and instance members (inside the __dict__ member of instances) but they are there to find.

Debugging IronPython with SharpDevelop

There is an alternative way of debugging that also allows you to debug with a different version of IronPython. In the 'Tools -> Python' section of the options dialog you can change the version of ipy.exe that SharpDevelop uses for debugging. You then need to set some command line options to start IronPython with -D so that it generates the necessary debugging information. In the Start Options add the following command line arguments, changing the name of your main file as required:

-D ${ProjectDir}\

If you do this then you need to explicitly add references to the .NET assemblies you use (except for System which is included by default) using clr.AddReference.


Overall excellent support for IronPython, especially when compared to Visual Studio. SharpDevelop does however fall down when compared to more specific Python IDEs; lacking features like intellisense, calltips and even Python oriented auto-indent. These features are ones that I consider essential for general development but I will be keeping a careful eye on how SharpDevelop progresses.

Even though I don't use it as my main IDE I am keeping it installed so I can use the debugger when I need it.

Wing IDE

The Wing IDE by Wingware is my favourite Python IDE and I use it for IronPython as well. Wing is a commercial IDE and I use Wing IDE Professional.

The Wing Python IDE

Wing features include:

  • Built-in Python shell, this is a CPython shell and not IronPython, but it is very useful for trying out snippets of code
  • Project and code broswer
  • Autocomplete (intellisense) with type inferencing for Python code
  • Goto-definition
  • Auto-indent and indentation analyser
  • Source assistant (calltips)
  • Version control integration (CVS, SVN, Hg, Bzr)
  • Straightforward scripting API for integrating your own tools

A huge number of standard editor features (including Visual Studio, Vim and Emacs keyboard personalities):

  • Brace matching
  • Structural code folding
  • Syntax highlighting
  • Split views
  • Templates/Snippets
  • Block selection, block commenting, block indentation

Because Wing analyses Python code to provide its intellisense it doesn't know anything about .NET types. Wing comes with a script that generates '.pi' (Python Interface) files from external libraries. I worked with the Wing team to ensure that this script,, runs under IronPython and can generate .pi files for .NET libraries. With these in place you get intellisense and calltips for .NET libraries.

The .NET libraries are huge, so generating PI files for all of them puts a strain on the Wing sourcecode analyser. In practise I've found that generating PI files for the namespaces I use most frequently, which amounts to over 20mb of PI files (!), is a good compromise. As you move through the autocomplete options for .NET types the docstrings (pulled from the XML documentation by IronPython) for .NET types and methods are shown in the source assistant in the toolbar to the right, along with the call signature and return type. Wing understands the return type, so you get intellisense on values returned by calling .NET methods. In some ways this works better than the type inferencing of Python code, which is one of the advantages of static typing.

There are some limitations to this (at the moment it doesn't provide these calltips for properties) but it is still extremely useful.

.NET intellisense in the Wing IDE

The disadvantage of Wing is that it isn't integrated with the .NET environment. This means no Windows Forms designer and the very powerful Python debugger that comes with Wing only works for CPython and not IronPython. The integrated test runner tool doesn't work with IronPython tests.


You can configure the Python executable associated with a project. Switching the executable away from a standard Python interpreter and to the IronPython executable does allow you to run files with IronPython from the Wing user interface at the cost of breaking the integrated Python shell, which doesn't work with IronPython. This isn't a worthwhile trade-off in my opinion.

Fortunately extending Wing to add new tools is very easy through its scripting API. Scripts to run the current file with IronPython or run the tests associated with a file are simple to create. See my Wing and IronPython HOWTO for details of how to use for .NET intellisense and a Wing script for running the current file with IronPython.

Wing includes a standard set of scripts, including integration with PyLint, a code quality checking tool which is extremely powerful but notoriously fiddly to configure.

For debugging IronPython code you will need to use a separate tool, like pdb. This hasn't been a priority for me as practises like Test Driven Development, where you have unit tests that exercise small units of your code independently with virtually full coverage, greatly reduce the number of times that you need a debugger. It is something I have missed on occasions though.


Unlike the IDEs we've been looking at so far, Wing is a great Python IDE. Wing has the advantage of being cross-platform and can be used for working with IronPython and Mono on Mac OS X or Linux. Wing is also useful for both CPython and IronPython.

The scripting API is one of the killer features of Wing, it is very easy to extend (in Python of course) and integrate new tools. The intellisense and source assistant are its other killer feature and I find the Subversion integration, code browser and project browsers invaluable too. Unlike Visual Studio Wing isn't opinionated about how your project should be laid out, which makes it less of a pain to use with existing code.

By being a Python IDE rather than a .NET IDE there are features missing, especially designer and debugger support, and although the intellisense is very good it requires running an external tool on libraries you are using with IronPython. As few of the other IDEs have this feature at all, and there are other ways of getting a designer (I use Visual Studio Express generating C# for this) and debugger, Wing is my preferred IDE for IronPython development.

Eclipse and PyDev

Eclipse is the well known Java IDE. PyDev (free and open source) adds Python support to Eclipse. The PyDev Extensions improve the level of Python support and add IronPython support. The PyDev extensions are commercial and cost $42.50. There is a thirty day trial period for the extensions.


The PyDev extensions were made open-source on the 4th September 2009 and are now free!

Setting up your first IronPython project from scratch with Eclipse and PyDev is simple but involves quite a few steps.

  1. Download the Eclipse IDE, along with the Java Runtime Environment (JRE) if you don't already have it installed.

  2. Select the 'Help->Install New Software' menu option and from the dialog it brings up add the URL

    After selecting -- All available sites -- you will then have the option of installing PyDev and PyDev extensions:

Installing the PyDev extensions in Eclipse
  1. Once these two extensions are installed you have a new option under the 'File->New' menu item: 'Pydev project'. If you select this you get to choose between Python, Jython (Python for the JVM) and IronPython for your new project. The first time you do this you need to configure an IronPython interpreter and select which locations will go on the PYTHONPATH. This last step determines which modules PyDev knows about for its autocomplete. Directories in your IRONPYTHONPATH will automatically be on the list for you to
Setting the IronPython interpreter

Eclipse with PyDev has intellisense for Python objects (trigger with ctrl-space) and standard IDE features like goto-definition. Eclipse also has refactoring tools that aren't in Wing, plus it has automatic snippets (it automatically adds the parentheses and self parameter as you define a method for example and it fills in your import statements) which is nice but takes some getting used to.

Amazingly PyDev has intellisense for .NET objects! It does this using reflection, so when you first trigger it for a type you haven't used before it can block for a few seconds whilst it gets the list of members. It only works for assemblies that contain a namespace with the same name, which is thankfully most.

IronPython intellisense in PyDev

The intellisense uses .NET reflection (this is how the Python dir function works in IronPython), which can be slooow for types it hasn't seen before. Bringing up the intellisense options can sometimes cause a delay.

PyDev also has some integrated code quality tools and can warn you about things like unused variables. There is an integrated Python shell, and when working on an IronPython project the shell is an IronPython shell using the interpreter you configured for the project.

IronPython 2.6 console in Eclipse / PyDev

Debugging IronPython code with PyDev doesn't work at the time of writing. This will be added once the debugging APIs (like sys.settrace()) in IronPython 2.6 are mature. As with Wing features like designers, and for the moment debugging, will have to be done with external tools.


In many ways Eclipse and PyDev has the most powerful IronPython integration of all the IDEs we have looked at. It is a capable Python editor and the added features for IronPython are built very naturally on top of this. If I wasn't so familiar with Wing I might be tempted to switch. Scripting Eclipse is more complex than Wing, and it is more opinionated about things like project layout, but having an IronPython shell builtin is a nice feature.

It is at least slightly ironic that the largest Java IDE has better support for developing in a .NET language than Visual Studio.

Other Editors

For Python developers it is common to not use a heavyweight IDE but to use a programmers text editor. Vim and Emacs are both particularly popular in the dynamic languages community; lightweight tools for lightweight languages. These editors are easy to extend and integrate tools into, so support for code completion, debugging, refactoring and so on are usually available via plugins.

Popular IDEs for Python development include a mix of free and commercial IDEs:

  • Komodo
  • Stani's Python Editor (SPE)
  • Netbeans and Intellij both have nascent Python support
  • PyCharms is a new IDE for Python from Jetbrains
  • PyScripter
  • Pida (Support different Editors like Vim, Medit, Emacs)

Several of these IDEs are themselves written in Python.


I haven't used it myself, but it looks like at least some people are using Komodo with IronPython. Here's an email from the IronPython mailing list providing auto-complete for Windows Forms: Komodo .NET Intelliisense.

There is also at least one IronPython specific editor being developed: Davy's IronPython Editor (DIE). It is very young and lacks features like intellisense but is worth keeping an eye on.

Another project to watch is the Pyjama Project, which is the creation of the Institute for Personal Robots in Education. The project includes their own DLR based language, Pyjama Scheme, and an editor for DLR languages including IronPython.

The Pyjama DLR editor with IronPython

Other tools

Whilst programming it is rare that an IDE is the only tool in their toolbox, and if it is then you are seriously missing out. For Python developers, using editors like Wing, Vim or Emacs, it is normal to plugin external tools for use during development. For example if you are interested in testing the Python Testing Tools Taxonomy has over 80 to choose from.

Here are some of the tools, many of them well known by Python developers, you should consider using with IronPython.

Windbg SOS

After this introduction the first isn't a Python tool but a Windows one. Windbg (Windbag) is a Windows debugger and with the SOS extensions it can be used with .NET. At Resolver Systems we've used it for tracking memory leaks. Kamil Dworakowski, a Resolver One developer, has written up how to use it along with a couple of helper scripts for analysing heap dumps:

Code Quality Checkers

One of the advantages of statically typed languages like C# have over dynamic languages is that tools can deterministically follow code paths. With dynamic dispatch this is much harder as just about everything can be overridden, and many facts (particularly the type of objects) aren't known until runtime. Despite this there is a lot that can be known be by statically analysing python code and there are several tools for doing this with Python. Depending on which you use, and how you configure them, they are capable of performing many of the standard checks (unused variables, misspelled or undefined variables and members and so on) that you expect from statically typed languages.

There are three popular code quality tools with varying levels of capabilities and speed.

I've used both PyFlakes and PyLint with IronPython code. They statically analyse code, so although they run under CPython they work fine on code written to run under IronPython. At Resolver Systems we have a build step that runs a comprehensive set of checks over our whole codebase with PyLint. This takes a while to run, so we also plug PyFlakes into our editors to check files either on every save or before running tests.

There is also another tool, called pyntch, the "Python Type Checker", which analyses program control flow and claims to detect type errors in Python code. I haven't tried it, but it looks like an interesting addition to the range of Python code quality tools:

Debugging and the Python Pdb Module

The standard Python debugger is pdb. This uses Python stack frames and sys.settrace(), so in versions of IronPython before 2.6 it hasn't worked at all.

In 2.6 beta 2 you can switch on Python stack frames with the command line options -X:Frames or -X:FullFrames. Dino Veihland explains the difference between the two options:

-X:FullFrames promotes all local variables into the heap. So you can always crawl the stack and look/change them for all methods.

-X:Frames only creates the frame objects and if something happens to make us promote local variables (e.g. a closure, or a call to locals(), exec, eval, dir(), vars()) then the local variables will be available for that specific method.

With frames enables some features of pdb work. For example:

>>> import pdb
>>> def f():
...     print 'hi'
...     print 'goodbye'
>>> pdb.runcall(f)
(Pdb) s
(Pdb) s
(Pdb) s
>>> pdb.runcall(f)
(Pdb) ?

Unfortunately the two features of Pdb that I use the most, pdb.set_trace() and pdb.post_mortem() ( don't yet work. To support these a new command line option is being added that generates the necessary tracing code, -X:Tracing, and will be supported in a future release (i.e. hopefully the release candidate and beyond).

Pdb isn't the only option for debugging with IronPython. Harry Pierson, the IronPython program manager at Microsoft, has been working on an IronPython debugger tool based on the .NET debugger Mdbg. You can read about the tool, both what it can do and how Harry developed it, in a series of blog entries he wrote:

To support the new APIs in IronPython 2.6 a new assembly has become a standard part of IronPython: Microsoft.Scripting.Debugging. From inside IronPython code you would normally use its features through the Python APIs in the sys module. The support it provides can also be used directly from C#, which is useful when you are embedding IronPython. Harry Pierson has another blog entry describing the new DLR debugger:

Code Coverage and Profiling

The standard tool for measuring code coverage in Python is called and is maintained by Ned Batchelder.

  • is a tool for measuring code coverage of Python programs. It monitors your program, noting which parts of the code have been executed, then analyzes the source to identify code that could have been executed but was not.

    Coverage measurement is typically used to gauge the effectiveness of tests. It can show which parts of your product code are being exercised by tests, and which are not.

    The latest version is 3.0.1, released 7 July 2009. It is supported on Python 2.3 through 2.6.

Again it uses the sys module APIs only available in IronPython 2.6. I haven't tried it with IronPython, but if it doesn't work then it is a bug in IronPython that should be reported...

It isn't the only way of getting code coverage information from IronPython. Another new feature in IronPython 2.6 is a profiler. Not only can this be used for performance profiling of IronPython code but it can also be used code coverage. Curt Hagenlocher, a core IronPython developer, explains how to use it in two blog entries:

As I practise Test Driven Development code coverage isn't often a metric I'm interested in, so I don't have much experience of working with the coverage tools here.

For profiling Python does include a standard tool in the form of the profile module. Again these may work with IronPython 2.6, but the recommended profiler is written in C (cProfile) and obviously won't work with IronPython. The pure-Python alternative implementation has a high overhead and will interfere with the results, which is particularly bad in a profiler. For profiling IronPython it is probably wise to stick with the IronPython profiler or see if .NET tools can be adapted to work with IronPython.

Refactoring and Complexity

Two tools for automatic refactoring of Python code. It shouldn't be necessary to run these with IronPython to use them on IronPython code but I haven't tried either of them.

Rope is a relatively new-kid-on-the-block, but Bicycle Repair Man has been around for years and if you are using a popular Python IDE then someone has probably already written a script to integrate it.

For measuring the cyclomatic complexity of Python code you can use the Complexity Analyser by Curt Finch:

Where Next?

The next article in the series is about integrating with the .NET framework; the dark corners of IronPython that previous experience with Python or C# alone will not have prepared you for:

There are plenty of other places to turn for more information on IronPython. Here are a few other suggestions:

For buying techie books, science fiction, computer hardware or the latest gadgets: visit The Voidspace Amazon Store.

Hosted by Webfaction

Return to Top

Page rendered with rest2web the Site Builder

Last edited Fri Nov 27 18:32:35 2009.