IronPython is the codename for an alpha release of the Python programming language for the .NET platform. It supports an interactive interpreter with fully dynamic compilation. It is well integrated with the rest of the framework and makes all .NET libraries easily available to Python programmers.
Post a Comment
Member since:
---
Member since:2005-07-06
IronPython worked fine with Mono when it was on version 0.6, but I don't know how is it now.
Anyway, you probably should check Boo, it works with Mono and IMHO is more exciting: http://boo.codehaus.org/
Member since:---
Member since:
2005-07-06
Member since:---
Member since:
---
If you mean to imply that Boo is not as mature, you need to look again. To the best of my knowledge it is much more mature at present than IronPython, and the best way to think about it IMHO is C# done right. Boo is an excellent language for rapid application development, and is much more exciting than Python because I don't have to worry about the 'weak typing' found in the latter language. Besides, their syntaxes are almost the same.
Member since:2005-07-06
Yeah I would say Boo is on a more advanced state than IronPython too..at least the community seems much more active and "engaged" (though that's subjective of course), and you have some nice goodies such as integration with SharpDevelop IDE (auto-completion, stuff like that).
IronPython's website OTOH is not very welcoming...no tutorials, nothing.
Still, I am looking forward to have support for IronPython inside Visual Studio.Net, I would *love* to start developing ASP.Net apps on it instead of C#.
Member since:
---
Member since:2005-07-06
Member since:---
Member since:---
Member since:2005-06-30
No argument on a Wiki dedicated to the language in question will determine if Python is strongly typed or not. The term is overused considerably to mean any number of things to people.
In Python you can change the type of an object to another. Since the original constructor hasn't necessarily been run and the object's dictionary doesn't necessarily have all of the members defined for the new type in its constructor, this will result in an runtime exception if any of these are visited. If you have any class invariants, this newly 'casted' type may not conform to them.
There are a number of conversions to contend with, even when subclassing. Subclass type int (with new style classes, of course) and add a new method. Now call one of the destructive operators. Now you have an int again. Since the destructive operators rebind this isn't especially surprising, but it's also not what you want either.
You can add members and methods to individual objects, so that a particular instance of type X will support specific methods while another instance will not. What is the type of this instance?
You can create an instance of X, add methods to just this instance to overshadow all of the methods of X so that isinstance will say that it is an instance of X, but having entirely different behavior. Perhaps breaking any implicit contracts about the object while maintaining the same interface.
Member since:---
There are two issues here: assertion by an object that it adheres to a protocol, and enforcement that it does. In most statically typed language like C++, you have the benefit that type safety yields both protocol assertion and enforcement, except for those pesky virtual methods.
Python takes a more laissez-faire approach, the benefit being that you don't have to subclass like crazy to get the fine-grain control necessary in specific situations, the same reason for having virtual methods. Still, there remains the problem of predicting an object's behavior. Interface specs are the way:
http://www.python.org/peps/pep-0245.html
You can share code and rely on an advertised spec to predict behavior. I grant that people, not the interpreter, do enforcement of such specs, just as when you have virtual methods.
Member since:
2005-07-08
Boo is a lot better than this. Not only that it is cleaned up Python, it also allows for powerful macros through code generating attributes (outside the method) and macros (inside the method).
Boo.Lang.Useful.dll
[Disposable]
class Foo:
pass
It automatically generates the complete disposable pattern for you. It's a ton of code for interface with one method. It saves you from all that.
[AsyncMethod]
def Foo():
It automatically creates the BeginFoo/EndFoo async wrappers.
fileAndForget foo.BeginBar()
It automatically calls EndBar().
[Sigleton]
class Foo:
pass
It automatically generates sigleton code.
class Foo:
private bar as Bar = Bar()
[Handles(bar.Click)]
def BarClick(sender, e as EventArgs):
pass
VB-style declarative event handling.
PS: More info here: http://docs.codehaus.org/display/BOO/Boo.Lang.Useful
Member since:
2005-07-07
It strikes me that this is the perfect oportunity for MS to gain some points with OSS people - by open sourcing their implementation of IronPython (since it started that way anyway).
Just to be fair though, it is possible that they have used licensed code in the implementation that cannot be open sourced.
Member since:2005-07-08
Member since:2005-07-06
Member since:
---
Member since:2005-07-08
There are already commercial producs that use Boo.
http://boo.codehaus.org/Boo+Applications
Member since:---
Member since:
---
Boo is better suited to be considered a Pythonesque replacement for C# rather than a replacement for Python. Consider the lack of dynamic import. The recommended best practice for dealing with muliple-script-code in Boo is to use NANT! Boo is a great language, but many things like this indicate it's not for developers looking to use Python's style on .NET.
I use Boo, mostly because IronPython isn't available on .NET 1.1. Boo has some amazing improvements over Python, but I'm still planning on using IronPython when .NET 2.0 is out of beta.
Member since:---
Member since:
2005-07-08
Mixins are comming. You'll be able to include code from other files in another file.
The preprocessor is comming too. Look at the mailing list, come in the irc channel, reald logs. You'll know what's comming. All the good stuff from Ruby/Python (except the ugly stuff) will be there.
Member since:
2005-07-07
http://boo.codehaus.org/Gotchas+for+Python+Users
As discussed on the page, you don't import one boo script from another like python. You just pass multiple scripts to the boo compiler at the same time instead.
If you really want that, they could add something like #include to include another file, but it doesn't seem like something for which there is a major need.
Member since:
---
Member since:
---
