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.'"
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.
Is there anything the MONO team can do to improve support for dynamic languages?
Though this would probably break their binary compatibility with MS's implementation.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
A Python front end for Gcc could be fun. And nearly impossible. I suspect that Python's way too dynamic to be handled by anything but a run-time interpreter.
"The urge to fly from modern systems, instead of moving through them to even greater, fairer things is, I think, an indi
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.
CLR is starting to become a prominent candidate for "open source development platform". Things like IronPython just make this sweeter. One-off interpreters are just a waste of time these days. You can get immense value by creating a generic-enough VM (like Parrot or CLR or JVM) and running <your-favorite-language> on it. Then you get all the benefits of consolidating effort on making the platform better. Next up should be PHP and Ruby (if they haven't already).
It's 10 PM. Do you know if you're un-American?
I can't speak for the term in general, but in Python it means variables can have different types on different times, while still being strongly typed.
a = 1
Now a is an integer (actually what happens is this: an integer object is created, with the value 1, and the name a is bound to it)
a == '1'
Returns False: objects with different types can not be equal.
a = '1'
A new object is created, containing the string '1'. a now binds to that new object.
a == '1'
True.
Somewhat more useful: file objects implement a number of methods. If you write a class that implements those methods (often a subset is enough), you can use it any place where you can use a file object. No need to derive from file class. Of course this doesn't work only for files, it can be used for anything.
This sig under construction. Please check back later.
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:Nevertheless, Python is a strongly-typed language; this will raise an error:(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:This is bad, bad code in real life, but it proves the point.