Mea Culpa

I was so excited about getting IronPython 2.7.2 out the door, I briefly dropped my common sense and made a change to IronPython that never should have been made without triggering another RC release. So what the hell happened?

The change in question is f8cce37. The correction is 4a76497.

What Broke?

The property in question – MaybeNotImplemented – checks to see if a method’s return type has the MaybeNotImplemented attribute, which tells IronPython that the operator may return NotImplemented; this indicates that the attempted operation doesn’t work and that other options should be tried. Without specifying [return:MaybeNotImplemented] on a native method, IronPython won’t generate code to perform the other operations.

Windows Phone Fixes

The issue that triggered the initial change was #32374. This is interesting in itself, as it turns out that MethodInfo.ReturnParameter is not supported on Windows Phone 7 – it exists, and it compiles, but it throws NotSupportException. Joy.

Since mobile support was new, I figured that making a change specific to Windows Phone should be OK. And it probably would have been, had I done what I originally intended and put the new WP7 code in an #if block and left the original code intact. But instead I decided that if the new code worked for both, why not use it?

Static Typing is Not Enough

Notice how small the fix is? MethodInfo.ReturnTypeCustomAttributes returns an ICustomAttributeProvider, which has the IsDefined method. As it turns out, MethodInfo also implements ICustomAttributeProvider. This means that the original fix compiled, ran, and worked for most cases, but failed on others. And they failed in the worst possible way – silently (except for the part where the program breaks).

But but but … TESTS!

Yes, the tests should have caught it. Unfortunately IronPython has been running for a while without paying much attention to the state of the tests, and there’s really no one to blame for this except me. Most of the CPython standard library tests fail at some point or another, which drowns out the useful failures in a sea of noise. This, of course, has to change, so for 2.7.3 I’m focusing on the much smaller set of tests specifically for IronPython (not those inherited from CPython).

After this, there’s no way 2.7.3 is going out without at least that baseline set of tests green, and once I get them in order all new contributions will have to pass the relevant tests. This should be the only time that I have to do an emergency release.

In the meantime, IronPython 2.7.2.1 is available, which fixes this issue.

Setting environment variables for MSBuild Exec tasks

MSBuild has an <Exec> task for calling external programs, but (bafflingly) it doesn’t allow you to set the environment the program runs in. In my case, I need to run a Python script with certain directories in the PYTHONPATH.

The Short Way

On Unix machines, this is trivial:

PYTHONPATH=”~/foo” python script.py

For Windows’ wonderful cmd.exe shell (which MSBuild uses to run Exec) it’s a little longer:

(set PYTHONPATH=C:\Foo) & python script.py

If you want, you can chain multiple set commands together to set multiple variables:

(set PYTHONPATH=C:\Foo) & (set FOO=42) & python script.py

To actually use this in the MSBuild file, you’ll need to escape it like so:

<Exec Command=”(set PYTHONPATH=C:\Foo) &amp; python script.py” />

Getting the quoting right for <Exec> can be tricky; I use the <Message> task for debugging the command line. Remember to use &quot; instead of double quotes.

The Long Way

This method takes more typing but is a bit more clear, especially if you have multiple variables to set. Actually, it can be used to store whole batch files inside the MSBuild file, if necessary.

<PropertyGroup>
  <PythonExec><![CDATA[
set PYTHONPATH=C:\Foo
set FOO=42
python script.py
  ]]></PythonExec>
</PropertyGroup>

<Exec Command="$(PythonExec)" />

A CDATA section is required because the newlines need to be preserved. When running an <Exec> task, all MSBuild does is write the contents of Command to a temporary batch file an execute. This just provides more than the usual single line command.

IronPython 2011 Survey

The IronPython team would like to know more about how IronPython is being used and what improvements people would like to see in 2012.

Take the IronPython 2011 survey!

NWSGI 2.1 Now Available

I’ve finally updated NWSGI to use IronPython 2.7: NWSGI 2.1. The only other change is that NWSGI.dll will be added to the GAC by default by the installer.

NWSGI 3 Update

The big feature of NWSGI 3 is decoupling it from IIS and ASP.NET, which involved creating an abstraction layer for web servers (which is funny, because that’s what WSGI is). Shortly after I started that, the OWIN project started, which has essentially the same goal. Since I hate duplicating effort, NWSGI 3 is on hold until OWIN stabilizes, which hopefully shouldn’t be too much longer.

First IronPython Bug Weekend Coming Up

The first IronPython Bug Weekend is this weekend, February 12-13, 2011. The purpose of the bug weekend is to get as many issues as possible looked at and fixed before the next pre-release of 2.7. There are a large number of issues in the issue tracker that need to checked to see if they are still valid (based on what I've seen, probably half of them are already fixed). If they're not reproducible, they can be closed; if they are reproducible, then patches are always welcome!

In particular, we'd like to get people who haven't contributed to IronPython before to chip in. It's really not that scary, I promise! To get started, check out how to get and build the source code and how to handle issues. If you have any questions, just ask – everyone is willing to help out.

To get in touch with the other bug weekend participants, there are two primary channels: the mailing list (sign up, view the archives) and the #ironpython IRC channel on freenode.net. If you're looking at a particular bug, make an update to the Bug Weekend spreadsheet, and make sure no one else is working on it either. It's a good idea to send a message on IRC or the mailing list as well.

Here's to a good bug-fixing weekend!