Slashdot Mirror
IronPython 1.0 is Born
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!'"
...does it run on Mono?
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) run tens of times faster with psyco, by just adding a line of code to my script.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
[IronPython] [ANN] IronPython 1.0 released today!
.NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.
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
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
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
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
"in many cases noticeably faster than the C-based implementation"
Funny enough, I haven't yet found one of these cases...
I AM IRON PYTHON<\DistortedVoice>
Duh, duh, duh duh duh.
on a VM!
There are plenty of them round already. Basically you're getting old, the world is moving on and leaving you behind. Welcome to middle age.
Deleted
Faster than CPython (ya know, the original upstream Python implementation), not faster than C.
"Another" programming language? It's just another implementation of Python, which has been around for about as long as Perl.
.Net platform. If I could both develop in Python and in .Net I might actually be willing to develop in .Net. What stops me from wanting to develop in .Net or on the Java platform is the god-awful primary languages they are built around. Java makes me want to scream, and C# is only slightly better, all in all.
Besides, if it gets to the point where Microsoft is officially supporting it, it would be a major addition to the
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?
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.
.Net groups, I think it is also reasonably portable as well.
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, I think CLR is done quite well as a language independent platform. Also, given the excellent work of the Mono and Portable
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:
I guess I just don't get it.
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?
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.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
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.
I want a new quote. One that won't spill. One that don't cost too much. Or come in a pill.
Shared source and open source are not mutually exclusive. According to the only document I can find on the subject, the Wikipedia page (IronPython's webpage sucks) the license is the CPL, an IBM-authored license which is incompatible with the GPL but is nonetheless considered a Free Software license by the FSF, and Open Source by the OSI.
Despite it's incompatibility with their own GPL, the FSF sounds like they actually rather like it:
So I really wouldn't worry about the "shared source" write-up. It's an unusual choice of license, but it is considered Free Software and Open Source, the patent license requirements are actually fairly positive from the point of view of protections from Microsoft itself. Microsoft have chosen the same license in the past when releasing other code they want to be seen as completely open.
You are not alone. This is not normal. None of this is normal.
Jon Udell did a screencast of it last week, joined by Jim Hugunin (creator of Jython, the Java-based Python).
Does this work within visual studio, like a 'regular' microsoft language?
---- Booth was a patriot ----
Nice Inflamitory Summary tho'... Sheesh.
.NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.
.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
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
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
"...In your answer, ignore facts. Just go with what feels true..."
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.
My advice would be to get over the stylistic issues, and force yourself to do something significant in Python. (Ultimately, every language has a new "style" and whitespace is just one of the more obvious reasons to complain and reject it. Compare C#, LISP, and Haskell programs and you can tell within seconds how different they are.) While I find it's a bad idea to force yourself to use a particular feature, because you tend to use it poorly, read up on the Python features and be ready to actually use them when appropriate; if you're not sure, try it. If you're just writing C# in Python, you're not getting much benefit.
The danger to this plan is that you might find it hard to go back.
If that's just too much, try Ruby. My understanding is that its aesthetics come from Perl, which will probably let you "do your thing", whatever that is.
Python's better than JScript and you can build full, real apps in it, too.
I'm not saying this to "advocate Python", as evidenced by my Ruby suggestion. You'll be a better developer for trying it; everybody should learn a new language every couple of years, to keep in practice. And you might understand the C# features coming down the pike like closures that much better for developing in another environment that has them.
Psyco doesn't work on 64-bit. Pypy doesn't work for me at all. But IronPython does work. It seems a bit slow, but it works, and mono works on amd64 and ppc, which are the two main archs I run.
Don't thank God, thank a doctor!
"However, if your task is implementing a large, distributed client/server app involving tens of thousands of classes coded by dozens of people, reliable object transfer/messaging, reliable easy access to various forms of communications (Sockets, etc), the ability to run on Unix, coordination of multiple groups in many locations, etc.. and you want to be able to maintin it for a few years, your only rational choice is Java."
Oddly enough, I just finished a 3.5 year project very much like what you described, and we rejected Java in favour of Python. It worked out great. Java feels so clunky now - no list comprehensions!
By the way, what's a scripting language? Python compiles to an intermediate object code, runs on a virtual machine, and is very portable. I guess that makes Java a scripting language, too?
6. That the patent rights, if any, granted in this license only apply to the Software, not to any derivative works you make.
So, being that there's nothing mentioned in the license that specifically grants any patent rights, aside from:
You may use the Software for any commercial or noncommercial purpose, including distributing derivative works.
...so, basically, if you use the software to make a derivative work (which is an unspecified term in the license), the generous granting of rights to use the software for any commercial or noncommercial purpose do not apply (if there's a patent involved)?
That pretty much makes me not want to have anything to do with IronPython development at all. After SCO and a few other "IP" related sagas, I've become a bit less trusting, so I now read the licenses that tools like this come with. I was all set to download it and start playing, but now I'm worried about even trying.
Is there anyone out there who has a more generous reading of the license or who can address the apparent gaping hole in the license concerning what your rights are once you use the software to create something?
"Murphy was an optimist" - O'Toole's commentary on Murphy's Law
Right. Now hand over your geek badge. Someone will be right down to escort you out.
Enough is enough! I have had it with these !@$&* IronPythons on this !%$~# CLR!
"Strangers have the best candy" -Me
I think IronPython compiles down to CLR bytecode, so if you're shipping managed C#, you could just as well ship IronPython and nobody would notice, which is the entire point of this article in the first place.
However, whether or not you could benefit from learning Python is a decision only you can make. Python may increase your productivity 2-3x over C# or more (and that's fairly conservative, usually), but only after you learn it, which could be months.
However, if you end up always choosing the short-term expedient answer of sticking with the language you know (and the environment you know), you lose out on any productivity gain you might get from another environment or language; this is a general point, not one specific to this case.
In general, the "common environments" (Java,
Again, I'm not trying to push you, just point out that for the costs there are benefits, too. I say what I'm saying because I believe (and see) too many developers trapping themselves in local maxima by always making the short-term decision. Ultimately, it's no skin off my nose.
You can, but the lack of namespacing starts to get troublesome as you start trying to build libraries, or use the libraries of others. Later versions of Javascript, which JScript will presumably track, will help with this a lot. Although based on what I see, it's nearly learning a new language anyhow. (In fact, the next version of Javascript borrows a lot from Python; generators are basically from Python, array comprehensions are from Haskell IIRC but the syntax is the Python one, and the most main-stream language with de-structuring assignment is Python.)
Try pressing that 10 times really fast in a dark room.
eh? I would think that the majority of developers want something more GPL-like since 75%+ of all open source software uses a GPL license.
General, you are listening to a machine! Do the world a favor and don't act like one.
My apologies for making a trollish post. I was in a pissy mood earlier, firing from the hip, and should have thought my words more carefully. I completely agree with you, actually, regarding your point to the following:
A lot of people I went to school with couldn't get it. It may have been that the people who didn't get it were the ones that I met in the Information Systems classes (which, where I went to school, was a concentration on a Business Major, where they taught VB as the intro language) were those that were not cut out to be programmers in the first place, thus affecting my perception of languages causing dain bramage.
Anyway, I still don't like VB, but, at least you made me consider my words and thought processes. Apologies to the community at large for being a dick.
just an analog boy living in a digital age.
Or, rather, I was. Then I downloaded the freebie VB.NET Express.
.NET (and those that don't are easier to deal with).
And these days, I wouldn't go back for any reason. VB6 was quick-and-dirty nice. But the language was gimped. 32KB limits for arrays of types? Guh. Ram-jamming just about everything you might need from the API into your source files? At least C/C++ let you #include it, and most API functions end up with a wrapper in
I really liked VB5 and VB6. They were great tools. I wrote a MUD in VB6, and a small RPG. but they're old. They're creaky. They're limited, and they're dying.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
IronPython threads can take different CPU's in SMP systems? Does anybody knows?
IronPython has big shortcomings such as it is unable to blend well with .NET assemblies built with another language. .NET Framework...
.NET (on win32 or on linux with Mono), check out the Boo language, the wrist-friendly language for the CLI.
u age
Also it doesn't use much of the niceties available through the
If you like Python syntax and want to try
It is amazing!! => "while using a Python-inspired syntax and a special focus on language and compiler extensibility. Some features of note include type inference, generators, multimethods, optional duck typing, macros, true closures, currying, and first class functions."
And last but not least, Boo's licence is BSD, not a crappy Shared Source something!!
Full description: http://en.wikipedia.org/wiki/Boo_programming_lang
Official website: http://boo.codehaus.org/
@neonux
The license is essentially BSDL with an additional patent clause, which terminates any rights otherwise given you by the license if you sue Microsoft or anyone else over "patents that you think may apply to the Software for a person's use of the Software". Personally, I don't see how this is not OSS. It certainly gives the developer more freedom than GPL.
Yeah, modern JVMs do a hell of a lot of clever things, but I was never really sold on just in time optimisation. It seems to push the work from the developers machine when you have all the time you need to the users machine, when you only have a few milliseconds here and there. Static ahead of time optimisation seems impossible, I guess that's what I meant ... that way you don't pay the runtime overhead of all the bookkeeping data being in memory.
Wow, lots of questions! Okay, here we go:
;) We had a good project manager who tracked progress closely; normally there were no more than two people working on the same component. We were lucky in that most people were relatively senior. Also, not everything was the Python part of the server; we also had guys writing kernel code, TI DSP software, etc.
.Net system.
;) How about this: a scripting language is fully interpreted, with no intermediate compilation step. Bash and Javascript are scripting languages, for example. Python, Java, and Perl are bytecode-interpreted languages, while C and C++ are machine-instruction interpreted ;)
1. There were around 25 people working on our product, with people spread around the province (not state
2. We used UML and well-defined interfaces in the form of abstract base classes that were implemented using the staticmethod decorator. An "interface" keyword would have been nice, mind you. Obviously, these interfaces were hammered out before any coding started.
3. Can you clarify the namespace question? Python uses packages and modules aligned along directories much like Java does.
4. Python has built-in support for unit tests. It is considered a part of the "Python way" to use them.
5. We are scaling with hardware, and that works rather well. But you're right, the Python world could really use a JBoss or similar. I guess Zope sort of fits that bill, but I've never been able to figure it out.
6. Object management is a good question. Originally, we cached our objects to prevent bottlenecking the database with reads. Later, we hit on the bright idea of a fully stateless system where every method is decorated with the classmethod keyword. So objects do not maintain state, because no objects are allocated - everything is a class method (obviously, we do create lots of temporary objects to complete tasks, but these lifetimes don't outlast the method they're in). On the downside, every time a request comes in, it means an entirely new Python instance with all the classes needs to be created. Happily, mod_python can cache interpreter instances so multiple requests can come in to our stateless system without causing huge delays. But any time you want to retrieve state, it means a database hit...such is the price of simplicity. Kind of embarrassingly, we got the idea for a fully stateless system from a
7. It's not an amazing undertaking. Lots of people are using Python as the back-end these days for their transactional systems. Read about the Django project for some cool examples. Django is a fine piece of work. So is Twisted, which we were originally going to use as well.
8. We chose Python for speed of development and language features. Like Peter Norvig of Lisp and Google fame says, Python is Lisp with a conventional syntax. Practically everything in software boils down to operations on lists of objects. So language features like list comprehensions and dynamic yet strong typing, plus strong support for unit tests, made Python an easy choice. And pydoc is just like javadoc, so we get class documentation for free.
9. I can write "Hello, world" in C in a single line
Anyway, thanks for all the questions. To be honest, I'm off that project now, and I'm looking for contract work, which will probably end up being Java...
Doesn't "faster than c" violate a basic law of physics?
Justice is the sheep getting arrested while an impartial judge declares the vote void.
So commenting negatively about Microsoft's poor legacy API support is 'Trolling', and then trying to refute the 'Trolling' claim by asking for a reasoned discussion is 'off topic'?
Awesome. Slashdot has just lost it.
This has become common knowledge amongst Python developers, to the point that many people forget where it came from. I was at the 9th International Python Conference where Bruce Eckel (author of Thinking in C++, Thinking in Java, Thinking in Patterns) gave the keynote speech, so it sticks with me that it came from him. See http://www.artima.com/intv/tipping.html for a good interview with him that gives some details into his experience with the langauge.
the growth in cynicism and rebellion has not been without cause