Usually, my PowerShell posts are effusive in their praise. However, who thought up this “feature” gets no praise from me:

In my opinion, this is a bad design. Resolve-Path assumes that if the filename being resolved doesn’t exist, then it must be an error. But in the script I’m building, I’m resolving the path of a file that I’m going to create. In other words, I know a priori that the file doesn’t exist. Yet Resolve-Path insists on throwing an error. I would have expected there to be some switch you could pass to Resolve-Path telling it to skip path validation, but there’s not.

And the worst thing is, I can see that Resolve-Path came up with the “right” answer – it’s right there in the error message!

Searching around, I found a thread where someone else was having the same problem. Jeffrey Snover – aka Distinguished Engineer, inventor of Powershell and target of Erik Meijer’s Lang.NET coin throwing stunt – suggested using –ErrorAction and –ErrorVariable to ignore the error and retrieve the resolved path from the TargetObject property error variable. Like Maximilian from the thread, using this approach feels fragile and frankly kinda messy, but I needed a solution. So I wrote the following function that wraps up access to the error variable so at least I don’t have fragile messy code sprinkled through out my script. 

The script is pretty straightforward. –ErrorAction SilentlyContinue is PowerShell’s version of On Error Resume Next in Visual Basic. If the cmdlet encounters an error, it gets stashed away in the variable specified by ErrorVariable (it’s also added to $Error so you can still retrieve the error object if ErrorVariable isn’t specified) and continues processing. Then I manually check to see if resolve-path succeeded – i.e. did it return a value – and return the TargetObject of the Error object if it didn’t.

As I said, fragile and kinda messy. But it works.

I’m just starting the third week in my new job – though between Thanksgiving and an intestinal virus, I’ve only been in my office for five days total so far. That’s not enough time to establish enough groundwork to be comfortable talking about what my team is doing yet. However, I just found out we’re still hiring and better yet there’s a public description of the job opening. So if you’ve ever thought “I want to work for Microsoft/Windows Division/With Harry”, here’s your chance! And if you aren’t looking for a new job, at least you can get some small hints as to what I’m doing in my new gig - “building substantial improvements into the Windows development platform” sounds interesting, doesn’t it?

Senior Program Manager(708846 -External)

Job Category: Software Engineering: Program Management
Location: United States, WA, Redmond
Job ID: 708846 9986
Product: Windows 
Division: Windows Division

Developers! Developers! Developers!

Developers are the key to the success of Windows and at the center of a software ecosystem that represents hundreds of billions of dollars. Our team is chartered with reinvigorating the Windows developer ecosystem by building substantial improvements into the Windows development platform (APIs, tools and the underlying infrastructure) and making developing for Windows fun!

The team is currently seeking a Senior Program Manager to help us achieve our mission. The ideal candidate will have:

• Strong core PM competencies with special emphasis on developer tools and collaboration skills.
• Proven track-record of delivering results in a cross-team (ideally cross-division) environment.
• Has been a Program Manager shipping key products for at least 6 years.
• Deep empathy for the developer as a customer; ability to empathize through 1st hand experience of writing apps some of the issues developers are facing with respect to APIs, tooling such as Visual Studio and SDK.
• A demonstrated track record of excellence and delivering in ambiguous V1 situations.
• Has Bachelors in Computer Science or engineering.

You know what the Agile Manifesto doesn’t have? Video of a “very formal ceremony” announcing said manifesto. Instead, we just have artistically rendered picture of what sure looks like Martin Fowler pointing at a white board while some of the other original signatories look on. Sure, it’s a cool picture, but wouldn’t it have been much cooler if they had captured that moment on video instead? Especially if it was video of them all standing around looking vaguely uncomfortable while photographers took their picture and someone gravely read the manifesto to give it artificially inflated importance.

I only watched ten seconds of the SOA Manifestoannouncement video before I realized there’s nothing to see here, move along, just a bunch of navel gazing from the usual SOA suspects.

Seriously, if you having a big announcement about how cool, earth shattering, significant or, hell, even interesting your manifesto is, then it’s not any of those things. It’s a waste of my time.

Then I noticed that my previous manager and personal friend John deVadoss is one of the signatories. I have metric tons of respect for John, so I gave the SOA Manifesto a second chance.

It lost me at the second sentence.

Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation. We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.

Are you frakking kidding me? “Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.” Who the hell came up with that? I didn’t realize the International SOA Symposium had a Department of Redundancy Department.

When you define SOA in terms of SO, then you can’t possibly score well on the practicality quotient.

The rest of the manifesto isn’t much better. What made the Agile manifesto great IMO was that it ran counter to “common” beliefs like “changing requirements late in the process is bad” and “shipping software cycles should take years”. Sure, we all realize how right those Agile manifesto guys were now, but at the time it was the next best thing to heresy for many organizations. Those guys were agents of change. And I mean real change, not “this will help me sell books” change.

SOA manifesto on the other hand is basically repackaged common sense. Stuff like “Recognize that SOA ultimately demands change on many levels” and “The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries” Any help figuring out what that change is or what the scope should be? Nope. Thanks for the advice guys, but I had your so called “Guiding Principles” figured out long ago.

But hey, I’m sure the manifesto will help Thomas Erl et. al. sell more SOA books. So, I guess from that perspective it’s mission accomplished.

It has been a very busy week for the IronPython team. Just under a week ago, we shipped a CTP for .NET Framework 4.0. Since then, we’ve shipped two – yes, two! – more versions of IronPython. Three releases in one week! If we could keep up that pace, we’d be shipping like 27 more releases of IronPython by the end of the year!

FYI, we’re not going to keep up the pace of shipping three releases a week for the next two months. We may be a little crazy on the IronPython team, but we’re not THAT crazy!

Actually, all three of these releases represent fairly small changes in the IronPython source tree. The .NET 4.0 beta was a CTP, so it’s basically whatever we had in our main trunk when they forked .NET Framework for the beta.

IronPython 2.0.3 is a minor point release in the 2.0 branch (duh). In addition to backporting some fixes from 2.6, we had to fix an CLR breaking change in partial trust on Windows 7. If you’re using IronPython 2.0.x in partial trust on Windows 7 you *MUST* upgrade to 2.0.3 (or 2.6 when it’s released). Sorry about that – but it was out of our hands.

IronPython 2.6 RC2 is – as you would expect - a minor update over the first release candidate. There was a memory leak discovered in the hosting APIs which forced us to do a second release candidate. Since we had to fix that, we took in a few of other fixes including some standard library changes (we left out json by accident in RC1 and Michael Foord got logging updated to work better with IronPython so we took the latest version of it). As per the release notes, we expect this to be the final RC and will re-ship it as RTM in about a month. Please start using this latest release and let us know if you find anything.

Big news in DevHawk land: I’ll be taking on a new role in the Windows division after I come back from TechEd Europe (plus a week vacation visiting my bro-in-law in Germany after TechEd).

You guys have heard of Windows, right? They just released a new version recently you might be aware of…Actually, I hear it was your idea!

Seriously, I am stokedto be joining the Windows team. I can’t say much about the new job beyond a) it’s in Windows Client (as opposed to Windows Server) and b) I’m working on a team that’s focused on the Windows developer experience. The Windows team is deep in what you might call “building on teh awesome that is Windows 7” but that they simply call “planning”, so sorry if specifics are kinda sparse. I’ll be back working for Mahesh Prakriya, who originally hired me into my current role on the IronPython team. Someday I might tell you the Mahesh PyCon Lego Story, but for now I’ll just say I was great working for Mahesh the first time and I think this time is going to be even better.

Working on Windows…focused on developer experience…for Mahesh - It’s like the perfect storm of work geekdom for me.

Of course, starting a new job means my time on the IronPython team is coming to an end. As excited as I am about this new opportunity in the Windows division, I’m a little sad to be leaving Developer Division and the IronPython team. I’ve joked with audiences that I care about Python because Microsoft pays me to care about Python, but that’s not completely true. Python is a fantastic language and IronPython’s combination of Python + .NET is hard to beat in my opinion. IronPython has made significant progress while I’ve been here the last eighteen months – two major releases (well, 2.6 is almost done), redisting the Python standard library, Visual Studio 2010 compat - but there’s still much for IronPython to accomplish. And of course, leaving behind such great teammates like Dino, Dave, Jim and Jimmy is ALWAYS hard.

The Windows team is somewhat tighter lipped than the totally transparent approach we use in IronPython. Not to worry, my evangelism skills were part of the reason I got the job so you’ll be hearing plenty from me soon enough. However, my posting here will be kinda sparse until I get my bearings over there. Until then, I’m sure that you will be absolutely fascinated by non-work-related-but-still-sometimes-geeky minutia I post on Twitter.

In case you’ve been hiding under a rock (or maybe just aren’t tracking developments in the .NET community outside of IronPython), Microsoft released Visual Studio 2010 beta 2 this week. Of course for me personally, the most important feature in Visual Studio 2010 is C# 4.0 new dynamic type (also available in Visual Basic, but since VB already supported some level of late binding it’s not exactly “new” to VB).

For those of you who want to experiment with this cool new feature, may I present IronPython 2.6 CTP for .NET 4.0 Beta 2. If you can’t think of any cool things to try with this new feature, the VB team blog has some scenarios to get your started.

Also available: IronRuby CTP for .NET 4.0 Beta 2 if you’re more into gemstones than snakes.

These are preview releases, which means they’ve gone thru basic testing. If you find any bugs, PLEASE report them via the usual channel. I wrote in my Post 2.6 Roadmap post, “we are committed to shipping the RTM of our .NET 4.0 version the day that Visual Studio 2010 is publicly available” but that means shaking out the bugs between now and then. We need your help so we’re ready to go by Visual Studio 2010 launch - March 22, 2010 as per Soma’s blog.

BTW, Alcides Fonseca suggested we call this release “IronPython 2.6 N4” since it’s designed to run on .NET Framework 4.0. I like that. What do you think?

In my last installment, I added support for a separate debug window on a separate thread from the main window thread. That way, I can pause the execution of the main window while the debug window stays responsive to user input. Now, let’s add some functionality to the debug window. I’m going to start by showing the source code of the python file being executed.

The TraceBackFrame instance has a property f_code that represents the FunctionCode object being executed in this frame. We have to explicitly cast to FunctionCode type because currently we’re exposing all properties that hang off TraceBackFrame as object type. Since Python is a dynamic language, we’re going to use reflection against the instance itself anyway so it doesn’t really matter what the return type is. However, I’ve asked Dino to change the TraceBackFrame type to use explicit types in order to make it easier to use SetTrace from statically typed languages like C#. Look for that in RC2.

After we cast the code object so it can be used from C#, we check to see if the currently loaded file matches the file currently loaded into the UI. I’ve ranted recently about the limitations of WPF’s TextBox but I didn’t want to get hung up syntax highlighting for this sample so I just went ahead and used the RichTextBox. In the DebugWindow Loaded event handler, I create _source as a WPF Paragraph and then wrap it in a FlowDocument and use it as the RichTextBox’s Document. I set the FlowDocument to be extremely wide, so as to avoid word wrapping. Then when I need to load a new source file, I clear _source of it’s current contents and add a single line run for every line of code in the file. This convention becomes useful later when I go to highlight the current line of code.

Once I load the current file, I save the current frame, code, result and payload in instance fields and then switch on result to determine what to do next. Currently, I’m just highlighting the relevant line of code and setting a TextBlock control in the menu bar.

In Visual Studio, we typically highlight the current line of code in yellow. However, that doesn’t work as great in a language like Python that delineates code blocks with whitespace. In ipydbg, I indicated function return with three carets. But I didn’t want to be modifying the text in the RichTextBox here so instead I used different colors for the different traceback event types: light green for call, light pink for return and yellow for line. The frame object contains the current line number, which I use for call and line, while the code object has the first line of the current code object, which I use for return. HighlightLine highlights the line in question with the colors provided and also scrolls that line into view if it isn’t already visible.

So now when a traceback is handled, it shows the text for the file being executed and highlights the appropriate line, based on the type of traceback event that happened. Now all we need is to have some way be able to continue execution. In the code, you’ll see I’ve defined a series of RoutedUICommands for common debugger commands. I’ve got the StepIn command wired up in the DebugWindow XAML to a menu item and the “S” keystroke. All that remains is to define StepInExecuted.

This function does three basic things: changes the dbgStatus text, resets all the text in the RichTextBox back to the default coloring, and sets the _dbgContinue AutoResetEvent which signals the main window thread that’s been blocked in OnTracebackReceived to continue.

With this post, I’m about even with the code that’s up on GitHub. That code has a few other capabilities – notably it will stop tracing if you close the debug window and it supports StepOut command which disables traceback for the current scope by returning null in OnTracebackReceived. But I haven’t implemented things like:

• Set Next Statement
• Viewing and changing variables
• Debugger REPL
• Breakpoint Management

Any suggestions on which of those would you like to see next?

I added traceback to my GetThings app in just two lines of code, but so far it doesn’t actually do anything that you would expect a debugger to do. But before we get to that, we need understand a little about how threading works for traceback debugging.

As I mentioned last time, the traceback debugger works by calling into the registered traceback handler at various times (entering/exiting a function, before executing a line of code and on exceptions). Execution of the Python code continues when the traceback function exits. That means that you have to block the execution thread while you let the user poke around with the debugger UI. For a console based app, that’s easy. For a GUI app, not so much.

At a minimum, you need to run your debugger UI on a separate thread from your main app window. If you want your main app window to be responsive while you debug, you’ll need to pump messages at a minimum (DoEvents in Windows Forms, similar approaches are available for WPF) or preferably run your python scripts on a background thread separate from either the main window UI thread or the debugger UI thread. To keep things simple, I’m going to simply block the main window thread while the debugger is active.

Since I’m going to have to setup a new thread for the debugger window, I decided to use a static constructor to centralize creating the thread, creating the window and registering the traceback handler all in one place.

As you can see, InitDebugWindow spins up a new thread and creates the debug window on that thread. Since it’s not the main WPF application thread, you have to explicitly call Dispatcher.Run to get the event queue pumping. You also have to explicitly set the apartment state to be single threaded for any threads creating WPF objects. Finally, I wait for the window to signal that it’s ready (it set’s the _debugWindowReady AutoResetEvent in the Window Loaded event) and then call SetTrace, passing in the debug window’s OnTracebackReceived event, on the thread that called InitDebugWindow.

It’s critical that you call SetTrace – and thus InitDebugWindow – on the thread that’s going to execute the Python code. Debugging in Python is per thread. Even if you execute the same code in the same ScriptScope with the same ScriptEngine but on a different thread, the traceback handler calls won’t fire. The way DebugWindow is written, it will only support debugging a single thread, but it would be pretty straightforward to support multiple threads by changing the way OnTracebackReceived gets signaled to continue.

Speaking of OnTracebackReceived, this was my initial basic implementation of it:

As we saw, the DebugWindow is running on a different thread than the traceback handler call will come in on. So OnTracebackReceived needs to invoke a new call on the correct thread by using Dispatcher.BeginInvoke. Even though OnTracebackReceived is always called on the main window thread, it still has access to the properties of the debug window thread like its Dispatcher. I used BeginInvoke to invoke OnTraceback asynchronously – OnTraceback isn’t going to return anything interesting and we’re going to wait on an AutoResetEvent before continuing anyway so I didn’t see any reason to use a synchronous call.

We’ll discuss OnTraceback more next post, but basically it will configure the UI for the traceback event that happened. Then DebugWindow will wait for user input. When the user indicates they want to resume execution, the command handler in question will set _dbgContinue and the original traceback will return so execution can continue.

In my series on Hybrid App Debugging, I showed the following code for executing a Python file in a hybrid C#/IronPython app.

The DLR Hosting API has three distinct levels of functionality. As simple as this is, technically it’s level 2 since it’s using a ScriptEngine directly. If you wanted to use the simplest level 1 hosting API, you could use runtimes instead of engines and save a line of code.

The ScriptRuntime version of ExecuteFile doesn’t include an overload that takes a ScriptScope like ScriptEngine does, so instead you add the items variable to the globals scope. However, this doesn’t automatically add the items object to every child scope – you have to explicitly import items into the local scope if you want to use it. So for Python, that means you need to add “import items” to the top of the GetThings.py script. Nothing else changes.

Personally, I find DLR Hosting API Level 2 to be straightforward and easy enough to understand, so I tend to code to that level by default. I actually had to go read the doc to discover the ScriptRuntime.Globals property and talk to Dino about importing those variables into a local scope. However, I wanted to point out that nothing in my Hybrid App Debugging sample so far is really dependent on the level 2 API. If you just want to execute some Python files in the context of your C# application, you can stick with the simpler level 1 API if you want. You can even use lightweight debugging with the level 1 API – there’s an overload of the SetTrace extension method for ScriptRuntimes just as there is for ScriptEngines. Just something to keep in mind.

Now that I’ve introduced my simple hybrid GetThings app, we need to set about adding support for debugging just the IronPython part of the app via the new lightweight debugging functionality we’re introducing in 2.6. Note, the code is up on github, but isn’t going to exactly match what I show on the blog. Also, I have a post RC1 daily build of IronPython in the Externals folder since I discovered a few issues while building this sample that Dino had to fix after RC1. Those assemblies will be updated as needed as the sample progresses.

We saw last time how how easy it is to execute a Python script to configure a C# app – only four lines of code. If we want to support debugging, we need to add a fifth:

You’ll notice the one new line – the call to engine.SetTrace. This is actually an extension method – ScriptEngine is a DLR hosting API class and but SetTrace is IronPython specific functionality [1]. If you look at the source of Python.SetTrace, you’ll see that it’s just a wrapper around SysModule.settrace, but it avoids needing to get the engine’s shared PythonContext yourself.

SetTrace takes a TracebackDelegate as a parameter. That delegate gets registered as the global traceback handler for the Python engine (on that thread, but we’ll ignore threading for now). Whenever that engine enters a new scope (i.e. a new function), the IronPython runtime calls into the global traceback handler. While the traceback handler runs, execution of the python code in that engine is paused. When the traceback handler returns, the engine resumes executing python code.

In addition to the global traceback handler, each scope has a local traceback handler as well. The TracebackDelegate type returns a TracebackDelegate which is used as the local traceback handler for the next traceback event within that scope. Traceback handlers can return themselves, some other TracebackDelegate, or null if they don’t want any more traceback events for the current scope. It’s kinda confusing, so here’s a picture:

You’ll notice three different traceback event types in the picture above: call, line and return. Call indicates the start of a scope, and is always invoked on the global traceback handler (i.e. the traceback passed to SetTrace). Line indicates the Python engine is about to execute a line of code and return indicates the end of a scopes execution. As you can see, the runtime uses the return value of the traceback for the next tracing call until the end of the scope. The return value from the “return” event handler is ignored.

So now that we know the basics of traceback handlers, here’s a simple TracebackDelegate that simply returns itself. The “Hello, world!” of traceback debugging if you will.

If you run this code, there will be no functional difference from the code before you added the SetTrace call. That’s because we’re not doing anything in the traceback handler. But if you run this in the debugger with a breakpoint on this function, you’ll see that it gets called a bunch of times. In the python code from the last post, there are three scopes – module scope, download_stuff function scope and the get_nodes function scope. Each of those function scopes will have a call and return event, plus a bunch of line events in between.

The parameters for TracebackDelegate are described in the Python docs. The frame parameter is the current stack frame – it has information about the local and global variables, the code object currently executing, the line number being executed and a pointer to the previous stack frame if there is one. More information on code and frame objects is available in the python data model (look for “internal types”). Result is the reason why the traceback function is being called (in Python docs, it’s called “event” but that’s a keyword in C#). IronPython supports four traceback results: “call”, “line” and “return” as described above plus “exception” when an exception is thrown. Finally, the payload value’s meaning depends on the traceback result. For call and line, payload is null. For return, payload is the value being returned from the function. For exception, the payload is information about the exception and where it was thrown.

As I mentioned above, python code execution is paused while the traceback handler executes and then continues when the traceback handler returns. That means you need to block in that function if you want to let the user interact with the debugger. For a console app like PDB, you can do that with a single thread of execution easily enough. For a GUI app like GetThings, that means running the debugger and debugee windows on separate threads. And as I alluded to, tracing for Python script engines is per thread. So next time, we’ll look deeper into how to use multiple threads for lightweight debugging a hybrid app.

[1] Eventually, I’d like to see IronRuby support lightweight debugging as well. However, there’s no built in mechanism for Ruby debugging the way there is for Python, so it’s less clear how we should expose debugging to the Ruby developer. We’d also want to build a language neutral DLR Hosting API mechanism for lightweight debugging as well at that point. But honestly, we have higher priorities at this point.

One of the IronPython scenarios that I’m hearing more and more about recently is for polyglot programs. In these scenarios, part of the application is built in IronPython other parts are build in compiled, statically typed languages like C# or Visual Basic. Sometimes, programs are written this way to allow the C# app to access a Python library, like my Pygments for WL Writer plugin. Other programs want to be customizable by the end user, like Intellipad. Whatever the reason, I think that the number of these hybrid polyglot programs is going up, which partially explains why the C# team added the new dynamic type to C# 4.0.

(FYI: the You had me at “dynamic” shirt above is available for sale in my Zazzle store along with my Architecture Help 5¢ shirt)

The thing is that if you’re going to build polyglot apps, you’re probably going to want the ability to debug polyglot apps as well. I’ve written extensively about building a debugger for IronPython. However, ipydbg uses the CLR debugger under the hood which means you have to have the debugger and the code it’s debugging in separate processes. That’s a huge design burden for building a debuggable polyglot application. Luckily, as of IronPython 2.6, we support Python’s built-in trace debugging capability (aka sys.settrace). While you can use this in pure Python apps (like PDB), you can also use it polyglot C# (or VB)/IronPython apps as well. If only someone were to take the time to build a sample and document what he did along the way…

Hey, that sounds like PM work!

Seriously, let me introduce you to the worlds simplest Twitter application: GetThings. The app downloads a list of my tweets via the Twitter API and displays them in a list box. The UI is written in C# while the tweet download code is written in Python. Clearly, this is a pretty brain dead app – but the point isn’t to build a great Twitter app but rather to show how to use the settrace API from C#.

I’ve stuck the code up on GitHub. If you want to see the basic app in action sans debugging, start with the initial checkin. As you can see here, basic C# / IronPython integration is pretty trivial. I’m simply creating an engine and a scope, adding the list boxes’ Items property to the scope, and executing the getthings.py file from the disk.

Since GetThings.py is just a text file, the user can modify it to get a list of anything they want – some other user’s timeline, the public timeline, or even – gasp! – something not from Twitter! In fact, as you see below, I’ve actually modified it to pull the tweets from a file on disk so I can avoid hitting the network on every run.

OK, so that’s the basics of the world’s simplest hybrid C#/IronPython Twitter application. Next up, I’ll add the settrace basics.

It’s not quite out the door yet, but things have gotten quieter around here since we shipped the Release Candidate of 2.6. But there’s no rest for the dynamic, so we’ve already started thinking about what we do next.

Since we shipped 2.0 last December, we’ve shipped two service releases: 2.0.1 two months later in February and 2.0.2 four months after that in June. We weren’t planning on doing a 2.0.3 release, but then we discovered the CLR folks made a breaking change to partial trust in Windows 7. David recently emailed the IronPython mailing list looking for feedback on other must-fix bugs we can get to for 2.0.3. If you’ve got an opinion on 2.0.3 must-fix bugs, please respond to that thread.

For 2.6 service releases, we’re looking to tighten up the timeframe a bit from last time. We’re planning to ship service releases of 2.6 in December and February. However, since we don’t have a major release ship vehicle in the 2.x branch until Python 2.7 next summer, these service releases may contain new functionality in addition to bug fixes. In particular, we will look to include any missing modules work that I discussed in my RC announcement post in these service releases.

In addition to the IronPython 2.6 service releases, we’ll also continue to track the Visual Studio 2010 beta cycle as it heads to RTM. I can’t comment on VS2010 dates, but I can say that we will ship a CTP of IronPython 2.6 for .NET Framework 4.0 for Visual Studio 2010 Beta 2 and that we are committed to shipping the RTM of our .NET 4.0 version the day that Visual Studio 2010 is publicly available. Given that dynamic the big new feature of C# 4.0, we want to make sure IronPython is ready to go as soon as C# 4.0 is available.

BTW, we are well aware that “IronPython 2.6 for .NET Framework 4.0” is a long ugly name. Any suggestions on a different one? We’ve been thinking “IronPython 2.6 R2” since the “R2” nomenclature is bigaroundhere. But “R2” doesn’t really capture the essence of the .NET 4.0 compatible release. Besides, when has the dynamic languages team at Microsoft ever done ANYTHING because it was popular with the Microsoft marketing folks? :)

At this point, we’ve got the next few months mapped out, but not much more beyond that. Specifically, we have two gaping holes in the roadmap:

• Visual Studio Integration
• IronPython 3.x

For now, I’m going to leave these holes unfilled. Currently, the rest of my VS Languages teammates (along with the rest of DevDiv) are heads down driving towards beta 2 of Visual Studio 2010. Once they reach that milestone, planning on Visual Studio v.next will begin. Those plans have the potential for impacting how the IronPython team proceeds going forward.

Frankly, several members of the dynamic languages team have been pitching in with the “drive to beta 2” effort so we’re a little more short handed than usual. If we get those people back, then we’re in a much better position to execute on both VS Integration and IronPython 3.x. If we don’t, then we have to make some hard choices about how to proceed. I’m guessing most would agree that VS integration is more important IronPython 3.x support. However, those aren’t equal efforts by any stretch of the imagination. How valuable is VS integration if, for example, we don’t have the bandwidth to build decent intellisense? As I said, hard choices.

If you want to make your voice heard on Microsoft’s level of commitment to IronPython, make sure you go rate the IronPython integration issue on Microsoft Connect. (while you’re there, rate the IronRuby integration issue too.) The IronPython integration is currently the top rated open issue on the VS Connect site and is the second highest vote getter out of all the Connect issues (active or otherwise) logged since VS 2010 shipped it’s first CTP! [1]

[1] Seriously, the next most recent Connect issue with more votes than IronPython integration is HttpRuntime.ProcessRequest() does not work in IIS7 Integrated Pipeline Mode from November 2007. The next one before that was Create Service Pack for Visual Studio 2005 from November 2005.

We released the IronPython 2.6 release candidate on CodePlex yesterday. If all goes well, this will be the ONLY RC and we’ll republish it as the RTW build in about a month. So if you’ve been holding off on experimenting with the 2.6 release, now’s the time to jump in with both feet.

As I’ve written before on this blog, this is a HUGE release for us:

• Python 2.6 features such as with statement, class decorators and byte literals
• Adaptive Compilation
• __clrtype__ Metaclasses
• ctypes and Frames support
• Lightweight Debugging
• 417 bugs fixed!

Anyway, with 2.6 winding down, the IronPython team finds ourselves in a unique position that we’ve never been in before: caught up. As far as I can tell, most of the Python community hasn’t made the move to Python 3.1 and Python 2.7 is looking like it will be released next summer. So IronPython is caught up with the latest version of Python most of the Python community appears to be using.

So that begs the question: what do we do now?

Of course, we want to hear from you regarding our next steps, but some things we are looking at include:

• .NET Framework 4.0
  We’ve shipped CTP releases of IronPython for each public beta of Visual Studio 2010 and  .NET Framework 4.0. You can expect that to continue as Visual Studio 2010 winds down and ships.
• Fixing Bugs
  417 bugs fixed is good, but there are still 839 active work items in our issue tracker. In previous releases, we’ve done minor bug fix releases every few months so we’ll probably keep up that cadence. Make sure you go vote for bugs you think are important.
• App Compatibility
  One thing we can do is take some of the more popular Python apps such as Django and Mercurial and make sure they run well on IronPython. In some cases, there may need to be changes to the Python apps to get them to run on IronPython (for example, see Jeff Hardy’s patch for running Django on IronPython) which assuredly means more time with lawyers for me.
• Missing Modules
  While IronPython 2.6 is our implementation of Python 2.6, there are binary modules we haven’t implemented yet like _csv, _ast and pyexpat. You could consider this App Compatibility work, but we have a different internal process for bug fixing and implementing new features so I broke this out separately.
• Documentation
  Invariably an area for improvement in all software, our doc story today is pretty much “go look at docs.python.org”. Of course, that doesn’t cover any IronPython specific functionality. Of course, what would be great would be to combine existing Python docs with IronPython specific docs in a single reference, which also assuredly means more time with lawyers for me.
• Tutorials
  If you haven’t seen Michael Foord’s Try Python, it’s awesome. However, it was recently pointed out to me that it doesn’t include any IronPython specific behavior (importing and interoperating with .NET types for example). The IronRuby Tutorial has specific IronRuby features and it would be awesome to do the same for IronPython. Of course, if we wrote new tutorials in reStructured Text, then I’m guessing it would be easy for Michael to include it in Try Python via his rst2xaml tool.
• “Just Text” in Silverlight
  If you haven’t seen MIX Online Labs Gestalt project, browse to one of the samples and View Source. Python as “just text” in the browser. Cool, eh? Jimmy is working on implementing the “just text” model for the Silverlight version of IronPython (and IronRuby).
• Visual Studio
  There’s no work item for VS Integration in our issue tracker, but there have been 112 votes for IronPython integration (as well as 79 votes for IronRuby integration) in the VS 2010 connect bug database. No promises here, but we are acutely aware of how popular this suggestion is.
• CodePlex Foundation
  The CodePlex Foundation is a new non-profit foundation sponsored by Microsoft with the explicit mission “to enable the exchange of code and understanding among software companies and open source communities.” As one of the oldest open source projects at Microsoft, we are very interested in the CodePlex Foundation as you might imagine. However, CodePlex Foundation is VERY new - everything is tagged “interim” for the first 100 days. Once the Foundation elects non-interim board members and establishes things like a charter and by-laws, you can be sure we’ll be investigating it more thoroughly. In other words, definitely more time with lawyers for me.

In case I haven’t said it lately, it’s great working on the IronPython team with Dino Viehland, Dave Fugate and David DiCato (The IronRuby guys aren’t bad either!). Also, I may whine about the amount of time I spend with lawyers, but honestly Yong, Kathryn and Kevin – our main LCA contacts – do a great job helping us figure out how and where to push the envelope so thanks to them as well.