Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

IronPython Moving Forward Again 61

Posted by timothy from the interesting-times dept.
immytay writes " Jim Hugunin (Jython, Numeric, and other projects) has issued the first release of IronPython since joining Microsoft in August of last year. IronPython runs on .NET and Mono and is supposedly faster than the C version of Python. This new version is 0.7, while 0.6 was released last summer and covered here. According to the IronPython mailing list, Jim has help from a Microsoft co-worker, and he plans to work toward IronPython 1.0."
This discussion has been archived. No new comments can be posted.

IronPython Moving Forward Again More

IronPython Moving Forward Again

Comments Filter:

  • Claim on 1.x times faster and alpha (Score:3, Interesting)

    by sporty ( 27564 ) on Wednesday March 30, 2005 @05:48PM (#12093710) Homepage
    To quote Dilbert, "Is it ok if we do things really fast and really wrong?" I'll be amused if they reach the same speed at 1.0 release.

    • Re:Claim on 1.x times faster and alpha (Score:1, Insightful)

      by Anonymous Coward
      Once the code is converted to IL code, the CLR is responsible for the speed. Since the CLR doesn't change much, I would say that if they get working code now, it will have the same performance in 1.0

  • Vs Psyco? (Score:2, Insightful)

    by Anonymous Coward
    I'd be interested in seeing how this compares to Psyco [sourceforge.net], the runtime compiler for regular Python.

    Psyco is also rather easy to use. For basic usage, put these two lines at the beginning of your program:

    import psyco
    psyco.full()

    ..and your program is magically faster! You can also combine with the Py2Exe utility to convert your project to an executable program (although it will still only be compiled at runtime).

    • I second this. Psyco is *great*. Unfourtantely its only for the x86 platform, although, so is the MS CLR :)

      • Re:Vs Psyco? (Score:2, Informative)

        by lupus-slash ( 132575 )
        Mono runs IronPython just fine on linux/ppc, OSX, amd64 etc.
        • would you mind telling us how well does it run on this platforms? IIRC iron python on .net is 1.8 times faster than CPython, and 1.3 times faster than CPython with mono on x86. How good is the performance on ppc wrt to CPython ? (I'm not sure if PyStone runs on ironpython, but that would be a simple number to read)
          • The ppc mono port has not been optimized as well as the mainstream x86 port, The pystones numbers are about 20% lower using IronPityhon on ppc vs CPython. Part of the issue is that the ppc systems I use still don't support the __thread C keyword which allows a faster runtime and GC implementation so my systems will benchmark a little slower.
            We expect to improve the port speed though, of course.
  • ...write a really really fast app in it to convert mounds of Perl code over within my lifetime. And then maybe they can make Windows more stable. And then...

    Screw it. I'll settle for the first thing if it ever happens.

  • Java and .NET Scripting (Score:4, Interesting)

    by fm6 ( 162816 ) on Wednesday March 30, 2005 @07:03PM (#12094677) Homepage Journal
    There seem to be a lot of Java and .NET scripting languages that are just ports of Python or Perl. I suppose these have their uses, but the disconnect between the language and the concepts of the underlying runtime strike me as a problem.

    Lately, I've become interested in Groovy [codehaus.org], a JVM-based scripting language that combines concepts from Java (syntax, access to the class libraries) with concepts from Perl (dynamic typing, native syntax for collections and regular expressions). It would be interesting to see something similar for .NET.

    • I'm not familiar with Groovy, but I find that Python and Java together in Jython is a good combo. I'm not sure what you mean by saying that Python is disconnected from the concepts of the JVM. At least at the language level, what I like about Jython is that Python and Java *are* different languages.

      Two great tastes...

      YMMV. Void where prohibited.
      • first of jpython is just too slow. with groovy you can compile the groovy script in to a .class and get the same performace (or the lack of ) as a regular java class.

        Well almost, as groovy uses reflection for method invocation, it is slower than regular java method call, but this is being worked on.

        The great thing about groovy is it supports junit from within, I have cut down my unit testing time drastically ever since I started using groovy.

        Plus forget about writing complex build.xmls for your ANT . You

      • By "disconnected" I mean that Python has its own unique approach to objects. It's been a while since I worked with Python, but as I recall, it has some very un-Javaish notions about creating ad hoc object types. I assume Jython implements some kind of compatibility layer to handle this difference in object semantics. Groovy, by contrast, deals with objects in precisely the same way as Java does.

        I'm curious to know what benefits you see from runing Python code on a JVM instead a native runtime.

        • Ok, I see what you mean about the different models of object. So far that hasn't been a problem for me.

          As to the benefits of Jython vs. CPython: Sometimes I like to use some of the Java libraries in a Python program, such as Swing. (Although most of the time, if I'm writing the whole thing in Python, its large library base is sufficient.) Often I use Jython because I have a program that's partly in Java and I'm using Jython to debug it, or write a test wrapper, or do something else using my Java code from
    • Groovy is a bad port or ruby without the amazing syntax beauty ( one of rubys main virtues )

    • Re:Java and .NET Scripting (Score:5, Interesting)

      by the quick brown fox ( 681969 ) on Thursday March 31, 2005 @01:30AM (#12097412)
      Check out Boo [codehaus.org]. It's really a phenomenal language, and much more mature and stable than the version number (0.5) would lead you to believe.

      Groovy has been taking a lot [pyrasun.com] of heat [manageability.org] lately. Boo seems not to suffer from the management/community problems Groovy has. In fact, Boo is just plain more exciting; Groovy is just Ruby disguised in Java syntax, as far as I can tell, whereas Boo takes what's best about Ruby (heavy emphasis on closures/blocks), Python (indent-based scoping, first class functions), and C# (static typing, properties, annotations, "using", p/invoke, .NET native), and one-ups them with type inference. It really does provide the best of both static and dynamic typing; there is NO compromise here as far as I can tell.

      As a bonus, the tool support is already very good. As with any self-respecting scripting language, it includes an interactive interpreter. (Boo scripts can be interpreted or compiled.) The Visual Studio .NET debugger already works with Boo, and if you write your Boo code in SharpDevelop (a free IDE for .NET platform) you can get code completion, syntax highlighting, code folding, etc. And since it's all statically typed, there is hope for IntelliJ-like refactoring tools, although I don't think any exist yet.

      Bottom line, I think any Python, Ruby, or Groovy fan should take a long, hard look at Boo. You will find a whole lot to like.

      • Re:Java and .NET Scripting (Score:1, Interesting)

        by Anonymous Coward
        Based on this post I went and downloaded Boo, SharpDevelop and the BooBinding for SharpDevelop.

        I must say that I'm thoroughly impressed!

        I started off exploring some features of the CLI and Boo was able to handle all of it with grace. Delegates are a joy to use since Functions are objects. The Type and reflection systems all work as expected. The Type Inference system is really innovative. It saves you typing through inference, but maintains strong type functionality with compile time error checking. Much

  • open source maybe, where's the community? (Score:5, Insightful)

    by mike_sucks ( 55259 ) on Wednesday March 30, 2005 @10:59PM (#12096611) Homepage
    As Edd Dumbil pointed out, there's a number of questions that need to be answered before it is worth getting behind IronPython, such as:

    - Is it actually Free Software?
    - Why do I need a passport account Passport to participate?
    - Why are you bothering to release source code if you're not willing to
    accept patches?
    - Why don't you want to get it working with Mono?

    And so on.
    • Err, here is Edd's post [usefulinc.com]. Whoops.
    • from www.ironpython.com

      IronPython-0.6 is now available as Open Source Software under the Common Public License version 1.0 [eclipse.org]. A single zip file containing both the source code and the binary executables can be downloaded below.

      • That's a start. It is Free Software, but too bad it isn't GPL compatible.
        • That's a very good start, and I think it should about stop there myself. The CPL has additional patent restrictions the GPL does not. In fact, it seems to be an all-around better license, except it is not GPL v2 compatible. Then again, the FSF doesn't think either Apache license, or a number of other licenses are compatible either. Just because they are not compatible with the GPL, doesn't necessarily make them a bad license. I think the FSF even had a statement on the CPL going something like (to paraphras
    • Why do you say he doesn't want Ironpython to work in Mono?
      • The first sentence on www.ironpython.com is IronPython is a new Python implementation targeting the .NET and Mono platforms.
      • Lupus@ximian said on the mailing list that ironpython 0.7 compiles with current SVN Mono code.

      So... what's the problem?

      This is what Hugunin said about accepting patches:

      Given the company that I work for, I would have to spend a LOT of time with lawyers working out the right contribution policy in order to accept even sm

      • Have a read of this message [dreamhost.com]. If some of these issues have been cleared up, then great!

        If Hugunin has issues accepting patches because of who he works for, then that's a shame. I'm glad he thinks that that may change post 1.0, but why will these issues suddently be easier to work around just because the code has reached a stable version? If they can be worked around, why not do so now?

        How long will it take for 1.0 to be released? Are people prepared to wait that long rather than forking, starting from scra

        • If Hugunin has issues accepting patches because of who he works for, then that's a shame.

          Of course it's a shame, but Hugunin might not be working on IronPython at all if MS didn't pay him -- which is better? You know, most employers put some restrictions on how their employees use their time.

          I'm glad he thinks that that may change post 1.0, but why will these issues suddently be easier to work around just because the code has reached a stable version?

          Hugunin thinks there are pros and cons to accepting

          • > Later, when the codebase is more mature, outside patches make more sense
            > (patches generally touch less code, there are less conflicts , easier to
            > review).

            Patches for FLOSS projects usually come in two forms: uber patches from major contributors and 2-line bug fixes from knowledgeable users.

            By rejecting the former, you're discouraging people from becoming intimately familiar with the codebase early on - when it is usually easier to understand, so you're less likely to get such patches later on
  • I suppose the main benefit I saw was a more palatable way to tap into the winforms api. Of course, as another poster mentioned, it still needs a lot of work to be usable.

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close