Skip to main content

IronPython keynote

The news from this morning's keynote is: IronPython released (at last). The running joke in Jim Hugunin's talk was pretending that it had only been two months since he joined Microsoft. In fact, it took about eight months to work out how to do an open source release once he got to Microsoft.

The new plan is to release every two weeks until there is a 1.0 release. There are one-and-a-half engineers working on IronPython. Jim is spending half his time evangelizing dynamic languages and Python within Microsoft. The hope is that the next version of CLR will have better support for dynamic languages (although it's not at all clear to me what that means).

The talk was basically the same as the talk he gave at Lightweight Languages in December, but stretched out to an hour. There was time for more demos and more technical detail.

Jim claims two advantages for Python running on .NET: It provides easy access to .NET libraries, and it leverages a substantial engineering effort on the .NET VM. He showed his standard demo using msagent. The demo crashed: "Look at this beautiful stack trace." He has used this demo to introduce people to Python, like C# programmers. The interactive interpreter has left the biggest impression on people.

On the other hand, he has seen C# programmers write this as their first Python program:
 from System import *

class C:
@staticmethod
def Main():
Console.Out.Writeln("Hello, World!")

He also had a demo of an Avalon GUI in Python. The basic demo was
trivial -- window, title, button. Jim was droll: "Doesn't that make you drool?
Don't you want to lick my screen?" He showed a xaml-generated GUI and
wrote some code to walk over the GUI objects -- basic introspection
and modification of individual widgets.

By relying on the .NET VM allows the IronPython implementation to stay
simple. IP 0.7 is about 80% faster than Python 2.4. The IP
implementation doesn't make any particular effort at optimization. It
has a straightforward code generator. From the bytecode, it looks
very much like Jython: use static fields in generator code for
constants, call into runtime implemented in C# for most real
operations -- "==" op calls "IronPython...Ops::Equal".

Guido asked: The generated x86 is somewhat larger than the Python bytecode.
Does the increased size cause worse cache performance? more misses
when you run the larger code?

Jim's answer: Based on experimental evidence, this isn't a problem. Memory
pressure is an issue in general, but he doesn't have any evidence that code size is the problem. The current IP implementation uses a lot more memory than CPython.

The next demo was loading a C# assembly into IP and calling a static method. The audience asked him to call a Python function from C#. He was entertainingly nervous about getting this part of the demo to work. He got a big round of applause when the demo worked. He passed a Python function into C# and had it called.

Next showed the debugger integration. The debugger shows a mix of IP implementation code and Python code. You can introspect on values in either language. The profiler works the same way, he said.

The standard for long-term compatibility is Jython. IP ought to run the same set of regression tests as Jython.

Some of the hard integration problems:
  • Can all strings by unicode? (Guido: Fine with me.)
  • What is the right locking policy? There's no GIL in IP, so what kind of concurrency should the builtin types allow.
  • Can we experiment with optional static types?
  • How to expose CLR-style methods on both Python types and on existing CLR types? For example, should a CLR ArrayList have an append() method like Python?
I asked Jim about the key differences between IronPython and Jython. The basic architecture of the two systems is the same, and his original IP talk looks at lot like his original JPython talk. I was standing at the microphone, so I didn't write down all the things he mentioned. There are a lot of differences that result from having C# instead of Java as the implementation language: Delegates (C#'s typed function pointers) make it easier to call between Python and C#. The generics support in the VM allows him to introspect on generic types and provide straightforward mappings to Python types; in Java, there is no way to recover the original generic types at runtime. Can't recall what else he said; I'll have to ask again.

Comments

Will Robinson said…
This comment has been removed by a blog administrator.
Jeremy Hylton said…
The first time I saw the talk I was most impressed with the integrated debugger support. Jim did a more substantial demo of that feature at LL4.

Popular posts from this blog

PyCon 2018 Call for Proposals is Open!

It’s here! PyCon 2018’s Call for Proposals has officially opened for talks, tutorials, posters, and education summit presentations. PyCon is made by you, so we need you to share what you’re working on, how you’re working on it, what you’ve learned, what you’re learning, and so much more.

Before we dive in, the deadlines:
Tutorial proposals are due November 24, 2017.Talk, Poster, and Education Summit proposals are due January 3, 2018.Who should write a proposal? Everyone!

If you’re reading this post, you should write a proposal. PyCon is about uniting and building the Python community, and we won’t advance as an open community if we’re not open with each other about what we’ve learned throughout our time in it. It isn’t about being the smartest one in the room, so we don’t just pick all of the expert talks. It’s about helping everyone move together. “A rising tide lifts all boats,” if you will.

We need beginner, intermediate, and advanced proposals on all sorts of topics. We also need b…

PyCon 2018 Launches New Site, Sponsorship Search

After two great years in Portland, PyCon is shipping off to Cleveland for the 2018 and 2019 renditions of the Python community's largest gathering. PyCon 2018 will take place May 9 through 17 with two days of tutorials, three days of talks, and four days of development sprints.

For more information, check out our newly refreshed website at https://us.pycon.org/2018/ and follow us here on the blog and at @pycon on Twitter.

New Website

The new site features a design centered on the historic landmark Terminal Tower, a 52 story skyscraper that overlooks downtown Cleveland. When it opened in 1930, the tower was the fourth tallest building in the world and the tallest building outside of New York City. Though its height no longer tops the charts, the tower and surrounding Tower City area remain highly important to the city. What once was a beacon to guide ship captains to Cleveland's port and airplane pilots to its airport, the tower now includes 508 LEDs that light up for the holida…

How to get ready for the PyCon development sprints

[A guest post by Kushal Das, one of the 2016 Sprint Coordinators]So — you have already decided to join in the PyCon development sprints! The sprints run for four days, from Thursday to Sunday after the conference. You do not have to be registered for the conference to attend the sprints! Some teams plan to write code over all four days, while some projects plan a shorter sprint if the organizers cannot stay for all four days.Can you start getting prepared for the sprint ahead of time? Yes!There are several things you can do ahead of time, that can save effort once you arrive at the sprints — and some preparations can even be made at home, before you arrive at PyCon:Have your operating system updated and patched — whether Mac, Windows, or Linux. This eliminates one possible source of problems with getting software up and running.Go ahead and install the version control system that will be used by the projects you are interested in. If you install both git and Mercurial on your computer…