IronPython Moving Forward Again

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."

Comments

Claim on 1.x times faster and alpha

[sporty]

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:Except for Mono

[nightski]

What you will find is that this is a bunch of BS. They took advantage of the new features in the .NET Framework 2.0 - which will be standardized in the CLI. .NET 2.0 isn't even out by Microsoft yet - so of course Mono isn't going to support it. But Mono is planning on eventually having full support for .NET 2.0. So it will work. Wait till 1.0 - everything will be working then.

Re:Phrase it any way you like

[chris_mahan]

Someobody expand on that: I believe ironPython is not compatible with .Net 1.0 because of python itself, something to do with dynamic allocation in python. It's something that is supposed to work in 2.0

Vs Psyco?

[Anonymous Coward]

I'd be interested in seeing how this compares to Psyco, 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).

Re:Vs Psyco?

[lupus-slash]

Mono runs IronPython just fine on linux/ppc, OSX, amd64 etc.

Re:Phrase it any way you like

[Keeper]

If you could demonstrate that the changes were superflous in nature, perhaps you'd have a point. But given that you have no idea what was changed or the reasons for it, you're just being paranoid (and/or trolling, given the nature of your post).

v1.1 of .Net lacked certain features necessary for running a dynamic language (ie: perf would blow). These features were added in v2.0 (ie: perf no longer blows).

Well maybe then they can...

[suitepotato]

...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.

Read. React. Regurgitate.

[Keith Russell]

nt

No, I think we need t.

Every platform that has a .NET implementation already has a native Python implementation, which makes Hugunin's work, while interesting, ultimately redundant. I would love to hear how this little side project reinforces Microsoft's monopoly power in operating systems.

Re:Read. React. Regurgitate.

[damiangerous]

Not redundant at all. It's faster than CPython, and it can use both CLR and Python classes as well as extend CLR classes with Python.

Java and .NET Scripting

[fm6]

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, 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.

Re:Java and .NET Scripting

[the quick brown fox]

Check out Boo. 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 of heat 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:Phrase it any way you like

[BerntB]

you're just being paranoid [...]
v1.1 of .Net lacked certain features necessary [..]

Without looking into the matter, it might be needed extensions. As you write.

But... I'm not even going to Google for info on protocols, file formats, etc, etc.

Microsoft has a long history of using the standard monopolist tactics of restricting interoperability.

They will hardly stop doing it even if ordered to do so by a court (see recent EU problems). You certainly know that, too, so you are being disingenious.

Re:Phrase it any way you like

[Keeper]

So that makes it's ok to react in a knee jerk fashion and point fingers without knowing the actual facts involved? How does that add anything useful to the conversation?

you can't use python classes yet

[llimllib]

It can *hypothetically* use Python classes - if you look at the release, there's not actually much there that you can use. As the compiler gets more stable and modern, you'll be able to use more of the python library (hopefully).

Re:Phrase it any way you like

[IainCartwright]

Paolo Molaro (one of the mono guys) said on the Ironpython mailing list:

"IronPython 0.7 compiles with the current mono from svn (not with the released 1.1.5, though the patch is minimal)."

And Jim Hugunin has said in the same place that if Ironpython does not compile because it deviates from the spec. then it is a bug and should be entered as such.

Try and avoid knee jerk reactions. You'll just annoy your high horse.

open source maybe, where's the community?

[mike_sucks]

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.

Re:open source maybe, where's the community?

[mike_sucks]

Have a read of this message. 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 scratch or getting behind an alternative effort right away? Will anyone still be around by then to be to be turned into an instant community? These things can't just get turned on or off.

If you'll still (lessend or not) need to get a Passort account and use gotdotnet to be part of the community, that will still be very off putting for many potential hackers. Having a Passport account is an identity theft waiting to happen. Why is required to be a part of the community? A web forum is a massively inefficient way of communicating when compared to a mailing list, why should people have to suffer it?

I still would want some answers to these (and Edd Dumbill's, Miguel de Icaza's and Paolo Molaro's) questions before getting behing IronPython. The fact that such questions are raised at all is troubling, however.

Re:open source maybe, where's the community?

[Jussi K. Kojootti]

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 patches, and that the cons currently outweigh the pros. Later, when the codebase is more mature, outside patches make more sense (patches generally touch less code, there are less conflicts , easier to review). I'm not sure his evaluation of the situation is 100% correct, but that does sound quite understandable to me.

I still would want some answers to these (and Edd Dumbill's, Miguel de Icaza's and Paolo Molaro's) questions before getting behing IronPython. The fact that such questions are raised at all is troubling, however.

Hugunin is participating in this discussion. Really, he seems to be quite reasonable (gotdotnet and the web forums seem to be just tools for him -- if people really want to use something else, then that's what's going to happen).

The fact that questions are raised is not troubling, it just means there is real interest on this project. Different people, groups and companies will always have differing opinions on how a project like this should be run. Since it's a free software project, this is not dangerous - 'wrong' decisions by the project lead will result in a fork (only if the project really is interesting enough to warrant that much work though).

Common Public License version 1.0

[captwheeler]

from www.ironpython.com

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