A Good Mix 3: Releases, Tweeting and DIE

Another selection of recent posts on IronPython related subjects. All the posts in this mix are by Harry Pierson and Davy Mitchell!

First, DevHawk (Harry Pierson) has some comments on recent IronPython releases.
This is the Dynamic Languages SDK for Silverlight that recently had a refresh for Silverlight 3. In this post Harry discusses XapHttpHandler, an ASP.NET handler for IIS that can dynamically build dynamic applications using Chiron. He particularly likes this feature as he wrote it!
XapHttpHandler does the same exact on-demand XAP packaging for dynamic language Silverlight applications that Chiron does, but it’s implemented as an IHttpHandler so it plugs into the standard ASP.NET pipeline. All you have to do is put the Chiron.exe in your web application’s bin directory and add XapHttpHandler to your web.config
Something else that got releases recently was the first alpha of IronPython 2.6. This version of IronPython will target Python 2.6, and performance improvements (particularly startup and import time) have been the major focus of this version. In this entry Harry talks about one of the new techniques IronPython uses to improve performance: Adaptive Compilation. Something else that will be in IronPython 2.6 is support for Python stack frames.
A recipe on the IronPython cookbook by Davy Mitchell, showing how to tweet with Yedda the Twitter library and IronPython.
DIE is Davy Mitchell's oddly-acronymed IDE for IronPython: Davy's IronPython Editor. In these two entries he discusses his plans for DIE and the release of an installable version.

Comments

  1. Startling footnote in Harry's IPy 2.6 post: "IPy is over 4000% slower than CPy on TryRaiseExcept. Python has a different philosophy on exceptions than CLR does."

    In practice (e.g. Resolver One) do you find that this affects your coding style, pushes you to write less pythonically in IPy?

    ReplyDelete
  2. The corresponding fact (from the Pybench stats that Harry links to), is that where an exception isn't raised (which is usually the case) IronPython is massively faster than CPython (although only hundreds of percent faster rather than thousands).

    In general the performance profile of IronPython is very *different* to CPython. This means that you have to optimise differently, but I wouldn't say the code is really less Pythonic. Where you are optimising for performance in CPython (or any language) you end up with code that isn't as pretty as you would like - but is necessary for performance. Thankfully this is isolated to the performance sensitive parts of your code.

    That said, and as Harry mentions, some Python exceptions are used for control flow rather than to indicate errors. Performance can be improved in IronPython by looking at whether the exception actually needs to be raised or whether an alternative control flow construct could be used. Hopefully this can be done 'under the hood' so that it doesn't affect the code you write.

    ReplyDelete
  3. Thanks for the comment, Michael.

    Hopefully this can be done 'under the hood' so that it doesn't affect the code you write.

    AFAYK is this already done by IPy, at least in part, or does hopefully mean that this is on the IPy wish list?

    ReplyDelete
  4. I'm pretty sure it hasn't been done already - unless you know otherwise?

    ReplyDelete

Post a Comment

Popular posts from this blog

Extending Abobe Flash Player and AIR with Python and Ruby

Should Python Projects Support IronPython and Jython?

Further Adventures of the Debugger