Forgot your password?
typodupeerror

IronPython 1.0 is Born 285

Posted by ScuttleMonkey
from the metal-snakes dept.
dougblank writes "IronPython version 1.0 was just released after 3 years of development. Jim Hugunin, the creator of Jython and the lead developer of the Shared Source IronPython, made the birth announcement earlier this week. From the announcement: 'I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM... I found that Python could run extremely well on the CLR — in many cases noticeably faster than the C-based implementation. [...] Shipping IronPython 1.0 isn't the end of the road, but rather the beginning. Not only will we continue to drive IronPython forward but we're also looking at the bigger picture to make all dynamic languages deeply integrated with the .NET platform and with technologies and products built on top of it. I'm excited about how far we've come, but even more excited by what the future holds!'"
This discussion has been archived. No new comments can be posted.

IronPython 1.0 is Born

Comments Filter:
  • Yes, but.... (Score:5, Interesting)

    by gnud (934243) on Wednesday September 06, 2006 @05:37PM (#16055898)
    ...does it run on Mono?
    • Re: (Score:3, Informative)

      by bogaboga (793279)
      It technically could run or to be more precise, it could run with minor changes. My question though is:

      Is it as easy to learn as [Microsoft's] Visual Basic?

      Can it be used to create GUIs, add [business] logic to these GUIs as easily as VB?
      • Re: (Score:2, Insightful)

        by Ana10g (966013)
        One other thing. Visual Basic from Microsoft is an IDE, and their name brand for a language. IronPython is not an IDE, so, no, it probably cannot be used to create GUIs and add business logic as easily as VB.
      • Re:Yes, but.... (Score:5, Informative)

        by lakeland (218447) <lakeland@acm.org> on Wednesday September 06, 2006 @06:49PM (#16056292) Homepage
        As a .net CLR language, it can integrate with any other .net language including VB.net very easily. This integration is tight enough that you can write each function in your program in a different language, or write the GUI in VB.net and the support code in IronPython.net

        No, it is not as easy for non-programmers.

        Can it be used to create guis...? Yes it can. At some point it could be made as easy as it is in VB.net; if I were on the development team then that would not be high on my priority list. Leave the toy languages for interactive GUI prototyping, and leave IronPython for code-driven development. However, that's just me and other people have different itches they want scratched.

        I see IronPython as a very valuable development and it will make interacting with standard Microsoft-only developers on windows much easier since I will now be able to use a language I like while maintaining 100% compatability and interoperability.
        • Re: (Score:3, Insightful)

          by cyber-vandal (148830)
          A GUI designer does not make a language a toy, it makes it a language where time is saved in building the GUI painstakingly trial and error fashion - time that can be spent working on the logic. And given that most languages have GUI designers now that would make them all toys, which, having learned C++, makes me wonder what sort of toys you had as a child :P
      • Re: (Score:3, Informative)

        by jma05 (897351)
        As far as I know, IronPython at the moment is not seamlessly integrated into VS2005. If you want VB GUI simplicity (drag control, add event handler), you might want to try Boo. Boo is well integrated into SharpDevelop (in fact SharpDevelop bundles Boo now). While, this is no Visual Studio, it does a pretty good job.

        Boo is not Python, but rather a middle ground between C# and Python. It is an easy to learn statically typed functional language with a Python inspired syntax.
      • Re: (Score:3, Informative)

        by sgt scrub (869860)
        Windows Forms is a way to create native, rich client GUI applications with .NET. Programs created with Windows Forms can be extremely good looking, and fully programmable IronPython.

        http://www.voidspace.org.uk/python/weblog/arch_d7_ 2006_05_20.shtml#e342 [voidspace.org.uk]
    • Re:Yes, but.... (Score:5, Informative)

      by jupo (717073) on Wednesday September 06, 2006 @06:32PM (#16056204) Homepage
      Sure does

      IronPython on Mono howto [google.com]

  • About speed. (Score:5, Informative)

    by Poromenos1 (830658) on Wednesday September 06, 2006 @05:41PM (#16055930) Homepage
    I found that Python could run extremely well on the CLR in many cases noticeably faster than the C-based implementation.

    Actually, that's not really something to be proud about (though I'm not downplaying the huge achievement of running python on the CLR). The C implementation of Python is not very optimised, and that's why projects like PyPy or psyco are trying to speed Python up (and succeeding very well). I've had CPU-intensive scripts (such as SortSize [poromenos.org]) run tens of times faster with psyco, by just adding a line of code to my script.
  • by Anonymous Coward on Wednesday September 06, 2006 @05:42PM (#16055934)
    [IronPython] [ANN] IronPython 1.0 released today!
    Jim Hugunin Jim.Hugunin at microsoft.com
    Tue Sep 5 13:27:12 PDT 2006

    * Previous message: [IronPython] ipy support in msxsl:script blocks
    * Next message: [IronPython] [ANN] IronPython 1.0 released today!
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    I'm extremely happy to announce that we have released IronPython 1.0 today!
    http://www.codeplex.com/IronPython [codeplex.com]

    I started work on IronPython almost 3 years ago. My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages. About 9 years ago I'd built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython. This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use - testified to by the large number of Java projects that incorporate Jython today.

    I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM. My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, "Why the CLR is a terrible platform for dynamic languages". My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR - in many cases noticeably faster than the C-based implementation. For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation.

    The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages. At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into. I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation. After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day.

    The first few months at Microsoft were a challenge as I learned what was involved in working at a large company. However, once the initial hurdle was over I started experiencing the things that motivated me to come here in the first place. The team working on dynamic languages in general and IronPython in particular began to grow and I got to have those great technical discussions again about both how to make IronPython as good as it could be and how to make the CLR an even better platform. We began to take advantage of the great new features for dynamic languages already shipping in .NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.

    We were also able to release IronPython publicly from Microsoft with a BSD-style license. In the agile spirit of the project, we put out a new release of IronPython once every three weeks (on average) over the course of the project. This helped us connect well with our daring early adopters and receive and incorporate their feedback to make IronPython better. We've had countless excellent discussions on the mailing list on everything from supporting value types to calling over
  • by creimer (824291) on Wednesday September 06, 2006 @05:45PM (#16055946) Homepage
    Is Python being used to fix Microsoft's mistakes? Or did a python got run through the Iron Chef competition? Either way, does it taste like chicken?

    Signed, IronConfused
  • Hmmm (Score:2, Interesting)

    by Anonymous Coward
    "in many cases noticeably faster than the C-based implementation"

    Funny enough, I haven't yet found one of these cases...
    • Re: (Score:2, Insightful)

      by ThePub2000 (974698)
      Most of the benchmarking takes place after the CLR loads up, which is why they can say that. For short stuff though, just the load time of the CLR to load the python interpreter can easily kill your start to finish times.
  • by Anonymous Coward on Wednesday September 06, 2006 @05:45PM (#16055949)
    <DistortedVoice>I AM IRON PYTHON<\DistortedVoice>

    Duh, duh, duh duh duh.
  • Snakes... (Score:4, Funny)

    by Cameron McCormack (690882) on Wednesday September 06, 2006 @05:57PM (#16056032) Homepage
    on a VM!
  • Dealing with UI (Score:4, Interesting)

    by Carcass666 (539381) on Wednesday September 06, 2006 @06:12PM (#16056101)

    So, if I'm using Iron Python under .NET, would I use be compelled to use WinForms at that point or would libraries like wxPython still be available?

    • by XMyth (266414)
      There's WX.NET

      http://wxnet.sourceforge.net/ [sourceforge.net]
    • by jsoderba (105512)
      A quick google shows wx.NET [sourceforge.net], a C# wrapper around wxWidgets. I haven't tried it, though. The Mono project provides GTK# along-side their Windows.Forms implementation, of course.
    • Re: (Score:3, Informative)

      by Tyger (126248)
      Probably not wxPython, but you would be able to use wx.NET [sourceforge.net] with it. (Though the development looks to have stopped on that judging by the timeline on that page.)

      It would be interesting to see how similar wxPython is to wx.NET with Python.
    • If you wanted to use wxPython, why would you be using .net anyway?
      • If you wanted to use wxPython, why would you be using .net anyway?

        Sort of "I want my cake and eat it too." It'd be nice to get all of .NET's framework libraries (insomuch as they are available in Mono), and to get the nice native-looking apps wx gives you on Windows and Linux (I'm not a huge fan of GTK+ on Windows, they never seem "native" but maybe that's just the apps I've run into and I'm sure that makes me lame, but whatever) -- this post isn't meant to debate the virtues of GTK, the parent was jus

  • by ndykman (659315) on Wednesday September 06, 2006 @06:13PM (#16056102)
    The snipped out part of the announcement seems to me to leave a bad impression. Given this is /., I can almost hear everybody filling the blanks with "and it's still is slow, because MS sucks" or the like, which is not the opinion or intent of the comment actually quoted.

    If you read the whole comment, you will see that in fact, the CLR implementation does very well, the designer is now at MS working on the CLR, and all in all, IronPython is a decent Python implementation.

    Given this work and the F# compiler work http://research.microsoft.com/fsharp/fsharp.aspx [microsoft.com], I think CLR is done quite well as a language independent platform. Also, given the excellent work of the Mono and Portable .Net groups, I think it is also reasonably portable as well.
  • Hrm (Score:5, Interesting)

    by IamTheRealMike (537420) <mike@plan99.net> on Wednesday September 06, 2006 @06:18PM (#16056126) Homepage

    Well, the links to the FAQ don't seem to work thanks to some kind of site move (I am asked to download the HTML instead of view it and ... well ... am too lazy tonight). But a few thoughts based on what is already there:

    • It says they are maybe 1.7 times faster than CPython, which is not that great, because CPython is incredibly slow and things like Psyco can give pretty big speedups (say 10 to 100 according to their website).
    • It seems fundamentally impossible to make a language like Python or Ruby fast. By their very nature everything has to be done at the last minute, based on string comparisons, and you can't do global optimizations really because at any moment the program might change itself and invalidate them. Consider the way every object can implement a fallback method that is called if somebody invokes "foo.bar" and bar does not exist in foo. It implies that every single method invocation must be identified by string not a number, and matched by string comparison.
    • If IronPython can't make Python fast .... seems like its only purpose is to give people who like Python and .NET some half way point between the two. But it's not quite Python, because you can't use its standard library, and it's not quite .NET so in a way you seem to get the worst of both worlds

    I guess I just don't get it.

    • Re: (Score:3, Interesting)

      by killjoe (766577)
      I think the point is to discourage the use of cross platform libraries and languages. MS figures if they can tie python programmers to windows then less programs will be written that can run on linux or the mac.

      The question is does ironpython run on mono.
    • Re: (Score:3, Informative)

      by squiggleslash (241428)

      It's quite simply an attempt to make Python available for .NET (and presumably the CLR in general.) That's it.

      This is the way programming is going. We're moving from CPU-specific unmanaged programming to platform independent abstracted managed environments. One day your entire operating system will run that way. But even today, you see these environments popping up in places where they add security and robustness.

      Web applications, for instance. So you have a giant web-app, maybe you're using components

      • This is the way programming is going. We're moving from CPU-specific unmanaged programming to platform independent abstracted managed environments. One day your entire operating system will run that way.

        Please god no.

        There seems to be an army of people dedicated to ensuring that we never actually see the benefits of faster hardware. We're throwing more crap layers of software on our machines faster than the CPU speeds can increase.

        All hail James Gosling!

        James Gosling is the person I curse at when I visit a
    • Re: (Score:3, Insightful)

      by kpharmer (452893)
      > It says they are maybe 1.7 times faster than CPython, which is not that great, because CPython is incredibly slow and things
      > like Psyco can give pretty big speedups (say 10 to 100 according to their website).
      > It seems fundamentally impossible to make a language like Python or Ruby fast.

      fast or slow are relative and somewhat meaningless terms.

      I use python to transform tens of millions of rows of data every day in the running of a data warehouse. C would be faster for most of these processes, bu
      • Sure, but that doesn't make fast or slow meaningless. It just means that for your specific applications performance isn't a big deal.
    • Re:Hrm (Score:4, Informative)

      by amix (226257) on Wednesday September 06, 2006 @07:27PM (#16056451) Journal
      But it's not quite Python, because you can't use its standard library

      Yes, you can, though not all builtins are available. All you need is this line in IronPython\Lib\site.py:

      import sys
      sys.path.append(r"E:\python24\lib")


      As for the rest of your comment: You do realize, that there are Python programmers on Windows ? I enjoy happily the ActivePython distribution, with which I can even automate my deskopt/applications. Now, in addition, I have full access to the .NET2 framework and can use IronPython to write cmdlets for PowerShell (aka: Monad).

      I consider this to be one of the best software-relases within the last few months.

    • Re:Hrm (Score:5, Informative)

      by swillden (191260) * <shawn-ds@willden.org> on Wednesday September 06, 2006 @08:56PM (#16056803) Homepage Journal

      Consider the way every object can implement a fallback method that is called if somebody invokes "foo.bar" and bar does not exist in foo. It implies that every single method invocation must be identified by string not a number, and matched by string comparison.

      It doesn't imply that at all. Smalltalk implementations figured out how to make that fast decades ago. The initial, most obvious, step is to hash method selectors so the lookups are done with numbers and to create a hashtable (either per-class, or global, with a sparse structure) for looking up method addresses given method selectors. There are a few optimizations that can be applied to make that pretty fast -- on the order of two or three times slower than C++-style vtable lookups. Next, many dynamic language implementations take advantage of the fact that nearly all method invocations are static -- the same line of code always calls the same method on objects of the same class, so there's no real reason to do any lookup at all. Such systems statically or dynamically rewrite the code, turning it into a simple test that the target object is of the "right" type, and then jumping directly to the method. Further, most method invocations can be proven at compile time (or at run-time, whichever is more convenient) to always go to the same target class, so even the object type test can be optimized away. Oh, and if it makes sense they can inline the method as well.

      That's just the little that I've read about, too. This stuff has been heavily researched by very smart people for a very long time now. The net effect is that lots of dynamic language implementations approach C code in performance, on average, and there are situations in which they can produce code that is even faster than a C compiler could, because they can make use of run-time information which is unavailable to any compiler that translates to "static" machine code.

      Python implementations may need work to make them faster, but there's nothing that says the language has to be slow.

    • Re:Hrm (Score:4, Informative)

      by costas (38724) on Thursday September 07, 2006 @02:18AM (#16057802) Homepage
      The point of Python is not to be blazingly fast. There are other languages (C, C++, pick your poison) if you want speed. The point of Python (and Ruby and even Perl) is to write code faster, especially for code pieces that are supposed to change often or have multiple versions (e.g. customized code for clients). And because Python is so readable/hackable, it's an excellent tool for that particular job.

      And if you want speed, I have two words: Boost.Python [boost.org]. It makes wrapping C++ code into Python near-trivial; I just wish they had some sort of quick-start documentation. I was intimidated by Boost.Python until I sat down to work with it. Sample (cleaned up) fragment from production code:
      class_<Loader, boost::noncopyable>("Loader", no_init)
      .def("name", &Loader::name)
      .def("addTable", &Loader::addTable)
      .def("load", &Loader::load)
      ;
      That little snippet exposes the Loader class to Python. Boost will take care of wrapping the code up into a Python shared library (.pyd), exposing the interface, converting between standard Python types and STL types, even converting C++ exceptions to Python exceptions.

      And if you don't want to go there, you could also use ctypes (part of the std Python distribution) and drive any win32 DLL using Python, unchanged.
    • Re: (Score:3, Informative)

      by Jimithing DMB (29796)

      It seems fundamentally impossible to make a language like Python or Ruby fast. By their very nature everything has to be done at the last minute, based on string comparisons, and you can't do global optimizations really because at any moment the program might change itself and invalidate them. Consider the way every object can implement a fallback method that is called if somebody invokes "foo.bar" and bar does not exist in foo. It implies that every single method invocation must be identified by string no

  • This is huge.... (Score:3, Interesting)

    by SumeyDevil (906408) on Wednesday September 06, 2006 @06:21PM (#16056142)
    This is huge, as now people have access to ALL the .NET libraries. Ironically, maybe Microsoft could be the company to take Python mainstream. First Google, now Microsoft...who's next? Additionally, anyone ever think how powerful Visual Studio could be if they implemented something like Parrot runtime into .Net?
    • by Nataku564 (668188)
      Parrot is a VM. I'm not entirely sure why you would stack VMs. One is more than enough.

      Of course, you may have meant Perl 6, the primary thing targeting Parrot, but they are quite distinct terms ... so ... dunno. Besides, with the way Parrot is going, you could just create a COLA -> CLR compiler and be done with it. That way the same language backend that produces COLA for compilation into PASM could be used and pipe the COLA into the equivalent CLR thingy and have everything work.
    • mod parent up. All these posts bashing IP and MS, this one hits on one of the coolest things about it - access to all the .Net libraries.
  • the "John Holmes" build.
  • Parrot (Score:2, Interesting)

    by Watson Ladd (955755)
    Yeah, they did screw up. Parrot will beat CLI for speed in dynamic languages by huge magnitudes of speed because it is designed for them. CLI is optimized for static languages. It's a very different idea. Calling conventions, instruction sets, internal types, even stack vs. register. They are very diffent animals.
    • Re:Parrot (Score:4, Informative)

      by gregorio (520049) on Wednesday September 06, 2006 @07:10PM (#16056373)
      Yeah, they did screw up. Parrot will beat CLI for speed in dynamic languages by huge magnitudes of speed because it is designed for them. CLI is optimized for static languages.
      1. RTFA. It talks about naive and uninformed (generated by hate) opinions like yours, and says that they are wrong.

      2. The CLR is optimized for static languages, but not innefficient for dynamic ones. In fact, that's all the article is about.

      3. RTFA!
  • by davmoo (63521) on Wednesday September 06, 2006 @06:24PM (#16056162)
    Instead of trying to impress us with innuendo and Microsoft bashing, the summary would have been a lot more helpful if it were written a different way. Oh, I don't know...like maybe for instance...TELL US WHAT THE FUCK "IRONPYTHON" IS! But then I guess, after all, that is the Slashdot Way. Why waste time on informative content when you can print Microsoft jabs instead.
  • by eastbayted (982797) on Wednesday September 06, 2006 @06:37PM (#16056221)
    Jon Udell did a screencast of it [infoworld.com] last week, joined by Jim Hugunin (creator of Jython, the Java-based Python).
  • Visual Studio? (Score:3, Interesting)

    by nurb432 (527695) on Wednesday September 06, 2006 @06:41PM (#16056241) Homepage Journal
    Does this work within visual studio, like a 'regular' microsoft language?
  • Typical Slashdot... (Score:4, Informative)

    by His name cannot be s (16831) on Wednesday September 06, 2006 @07:06PM (#16056359) Journal
    Nice Inflamitory Summary tho'... Sheesh.

    The whole (and far less baiting) summary:

    I started work on IronPython almost 3 years ago. My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages. About 9 years ago I'd built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython. This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use - testified to by the large number of Java projects that incorporate Jython today.

    I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM. My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, "Why the CLR is a terrible platform for dynamic languages". My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR - in many cases noticeably faster than the C-based implementation. For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation.

    The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages. At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into. I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation. After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day.

    The first few months at Microsoft were a challenge as I learned what was involved in working at a large company. However, once the initial hurdle was over I started experiencing the things that motivated me to come here in the first place. The team working on dynamic languages in general and IronPython in particular began to grow and I got to have those great technical discussions again about both how to make IronPython as good as it could be and how to make the CLR an even better platform. We began to take advantage of the great new features for dynamic languages already shipping in .NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.

    We were also able to release IronPython publicly from Microsoft with a BSD-style license. In the agile spirit of the project, we put out a new release of IronPython once every three weeks (on average) over the course of the project. This helped us connect well with our daring early adopters and receive and incorporate their feedback to make IronPython better. We've had countless excellent discussions on the mailing list on everything from supporting value types to calling overloaded methods. Without the drive and input of our users, IronPython would be a much weaker project.

    IronPython is about bringing together two worlds. The key value in IronPython is that it is both a true implementation of Python and is seamlessly integrated with the .NET platform. Most features were easy and natural choices where the language and the platform fit together with almost no work. However, there were challenges from the obvious cases like exception type hierarchi
  • by quick_dry_3 (112334) <steven@@@quickdry...net> on Wednesday September 06, 2006 @07:07PM (#16056361) Homepage
    just wanted to give a "cheers" to the MS dev team working on this.
    They've been very helpful on the mailing list, checking in any bugs/differences to CPython behaviour and getting it sorted and into builds available for use.
  • Enough is enough! I have had it with these !@$&* IronPythons on this !%$~# CLR!
  • IronPython threads can take different CPU's in SMP systems? Does anybody knows?
  • I just submitted an article, Boxing in the LLRing [telebody.net] I wrote about the Lightweight Languages Ring, a gathering of 300 developers at a boxing ring a week ago in Tokyo. For one thing Ruby's inventor is working on Yet Another Ruby VM and also the Python Language Update mentions IronPython.
  • IronPython has big shortcomings such as it is unable to blend well with .NET assemblies built with another language.
    Also it doesn't use much of the niceties available through the .NET Framework...

    If you like Python syntax and want to try .NET (on win32 or on linux with Mono), check out the Boo language, the wrist-friendly language for the CLI.
    It is amazing!! => "while using a Python-inspired syntax and a special focus on language and compiler extensibility. Some features of note include type inferen

For every bloke who makes his mark, there's half a dozen waiting to rub it out. -- Andy Capp

Working...