Slashdot Mirror


Super-Fast Python Implementation for .NET and Mono

Lansdowne writes "Jim Hugunin, the creator of Jython, has released an incredibly fast implementation of Python for Microsoft .NET and Mono called IronPython. Here's his PyCON 2004 presentation, including some benchmarks. He concludes: 'Python is an extremely dynamic language and this offers compelling evidence that other dynamic languages should be able to run well on this platform.'"

3 of 54 comments (clear)

  1. cool stuff by hattmoward · · Score: 4, Interesting

    I'm glad to see more alternative languages for the .NET/Mono platform... If we're gonna get stuck with it, we may as well make the best of it! :) Seeing Python run nice and fast, being a dynamic language and on a VM, is great stuff too.

  2. What changed? by ameoba · · Score: 4, Interesting

    I remember some previous attempt to do Python under .NET that was painfully slow & eventually written off as a failure and blamed on .NET's inability to handle the level of dynamism required to implement Python. What's changed since then?

    Are we looking at some sort of fundamental breakthrough in working with the CLR here or was the problem simply tackled by a more experienced/insightful developer?

    --
    my sig's at the bottom of the page.
  3. Re:Dynamic? by Jerf · · Score: 3, Interesting
    That's not the best way of describing how it works.

    In C, a "variable" is a box that contains things. The box is designed to only hold one kind of thing, so an "int" box can't hold a "char *".

    In Python, a "variable" is just a "post-it note" that can be stuck onto a value. The post-it note "a" can be stuck on to anything:
    a = 1
    a = "One"
    a = MyCustomObject()
    Nevertheless, Python is a strongly-typed language; this will raise an error:
    a = 1 + " some"
    (If you're on a Unix system, you most likely have Python installed. Type "python" on the command line and try typing that in.)

    Objects with different types are allowed to be equal, though there is some obvious danger with that. Here's a pathological case:
    class AlwaysEqual:
    def __eq__(self, other):
    return 1

    a = AlwaysEqual()
    a == 1
    a == '1'
    a == None
    This is bad, bad code in real life, but it proves the point.