Das deutsche Python-Forum

Hallo,

ich gräme mich wie man IronPython ( die DotNet-Python Version von Microsoft ) unter der DotNet-OpenSource-Implementierug Mono zum laufen bekommt. Ist das schon einmal jemandem der werten Forumsteilnehmern gelungen ?

Wenn man sich IronPython bei Microsoft herunterlädt findet man in dem Zip-Archiv ein Executable für Windows und den C#- Source-Code in Form vom MS-Developer Studio Projekten [ *.csproj ].

Bevor ich also das lange Herumexperimentieren und Basteln anfange frage ich zuerst einmal hier in die Runde :

- Hat jemand die Hürde schon einmal genommen und kann IronPython unter Mono auf Linux benutzen ?
- Oder kennt jemand ein Kochrezept ( bzw. einen Link zu sowas ) wie man die Übersetznung in Mono macht ?

Bin dankbar für jede Hilfe.

bernd_Aachen hat geschrieben:- Hat jemand die Hürde schon einmal genommen und kann IronPython unter Mono auf Linux benutzen ?

Ich selbst habe sie nicht genommen, aber es ist möglich. IronPython wird von den Mono-Entwicklern zum Testen ihrer .NET implementation verwendet. Wenn du eine neuere Version von Mono und eine ältere Version von IronPython nutzt, ist es möglich, dass es funktionieren wird.

Nimm doch gleich Boo [1]. Boo rockt einfach wie Sau!

[1] http://boo.codehaus.org

flummox hat geschrieben:Boo rockt einfach wie Sau!

Finde ich jetzt mal nicht. Boo ist eine Sprache deren Syntax Python ähnlich ist, aber viele Kompromisse mit .NET eingehen musste. Da ist IronPython schein weitaus.. pythonischer eben.

Boo probiert statisch typisiertes Python zu sein, und scheitert deswegen grandios. Zum einen weil es eine andere Semantik durch die Typisierung bekommt, und zum anderen weil es nicht mehr so dynamisch ist wie Python mit seinen Metaklassen und ähnlichem. Nichts für mich.

@bernd_Aachen: Warum willst du überhaupt IronPython unter Mono benutzten? Nur aus Spass?

Eher. Warum will man ironpython verwenden?

Geschmaecker sind verschieden. Ich liebe Boo einfach.

blackbird hat geschrieben:Eher. Warum will man ironpython verwenden?

Also ich kann mir schon vorstellen, dass man IronPython verwenden will (zwar nicht im aktuellen Zustand, aber in Zukunft). Was bekommt man da? Einen Compiler der IL-Code generieren kann und somit nicht von der Python VM sondern von den .NET VMs abhängt. Dies ist insofern praktisch, da Microsoft die .NET VM sowieso pushen wird. IronPython ist auch schneller als CPython, zumindest wenn man den alten Benchmarks glaubt. Last but not least kann man auf die ganze .NET-Funktionalität zugreifen (okay, kann PythonNet auch).

Vergleiche Jython.

Leonidas hat geschrieben:

blackbird hat geschrieben:Eher. Warum will man ironpython verwenden?

Also ich kann mir schon vorstellen, dass man IronPython verwenden will (zwar nicht im aktuellen Zustand, aber in Zukunft). Was bekommt man da? Einen Compiler der IL-Code generieren kann und somit nicht von der Python VM sondern von den .NET VMs abhängt. Dies ist insofern praktisch, da Microsoft die .NET VM sowieso pushen wird. IronPython ist auch schneller als CPython, zumindest wenn man den alten Benchmarks glaubt. Last but not least kann man auf die ganze .NET-Funktionalität zugreifen (okay, kann PythonNet auch).

klar. du bekommst .NET. Aber ausschließlich dotnet. Freu dich auf from System import Console und sowas Dein Code wird nicht mehr portabel sein und du bist windows gebunden. Alles in allem nur Nachteile.

blackbird hat geschrieben:klar. du bekommst .NET. Aber ausschließlich dotnet. Freu dich auf from System import Console und sowas Dein Code wird nicht mehr portabel sein und du bist windows gebunden. Alles in allem nur Nachteile.

Wer sagt denn das? ironPython läuft ja (manchmal) unter Mono, damit könnte man alos auch Gtk# benutzen oder Teile von Beagle oder was auch immer. Und sys.stdout bleibt natürlich da

Leonidas hat geschrieben:

blackbird hat geschrieben:IronPython ist auch schneller als CPython, zumindest wenn man den alten Benchmarks glaubt.

Die wurden doch aber noch zu Zeiten gemacht, als IronPython noch nicht "vollständig" war, oder? Ich denke mal, das gab dann eine ähnliche Leistung wie PyPy's "restricted Python" durch psyco beschleunigt. Eben eingeschränktes Python, welches sich gut von einem JIT-Compiler übersetzen lässt.

@Jens

Ich will mich mit IronPython befassen da die Integration in Dot.Net folgende Vorteile bietet:

1. Meine Kollegen coden in C#. Im Moment benutze nur ich Python um beispielsweise schnell mal ein Skript zur Systemüberwachung zu bauen. Daher können die Kollegen meine Klassen, die ich in Python baue nicht verwenden. Wenn IronPython einmal auch alle Python-Module unterstüzt können die Kollegen meine Klassen in ihren C# Progs verwenden.
2. Python eignet sich meiner Meinung nach hervoragend dazu schnell einen Prototypen für DotNet hochzuziehen und diesen danach Schritt für Schritt zu migrieren.
3. IronPython unter Mono eröffnet die Möglichkeit mit WindowsForms UserInterfaces unter Linux zu bauen. Unter Verwendung von Python. Das sind sehr gute Aussichten da meiner Meinung nach WindowsForms eine 1a-Klassenbibliothek ist.


Also wäre nur zum Spass untertrieben

Vielen Dank für Die vielen interessanten Beiträge.

3. IronPython unter Mono eröffnet die Möglichkeit mit WindowsForms UserInterfaces unter Linux zu bauen. Unter Verwendung von Python. Das sind sehr gute Aussichten da meiner Meinung nach WindowsForms eine 1a-Klassenbibliothek ist.

Wieviel hast Du bisher mit WindowsForms gemacht? Das ist wirklich Ansichtssache... Und ich weiß unter anderem auch warum Qt in der nahen Zukunft nicht verschwinden wird wenn ich mir den Hack namens WindowsForms angucke.

Ich meinte das ironisch.Stimme Dir zu. Trotzdem ist der Vorteil es zu können nicht von der Hand zu weisen.

Ich grabe zwar eine olle Kamelle aus, aber ich bin grad drüber gesolpert.

IronPython scheint, wenn man diesem Benchmark glauben darf, deutlich langsamer als normales Python und braucht mehr Speicher. Unter Mono wird IronPyhon dann wohl auch nicht viel besser laufen.

burli hat geschrieben:IronPython scheint, wenn man diesem Benchmark glauben darf, deutlich langsamer als normales Python und braucht mehr Speicher. Unter Mono wird IronPyhon dann wohl auch nicht viel besser laufen.

Ich denke dass dies schon unter Mono ist, wenn man davon ausgeht, dass es kein Windows Gentoo gibt.

Unten drunter steht

IronPython 1.1.1 (1.1.1) on .NET 2.0.50727.42

Daher nehme ich an das es sich um .NET 2.0 handelt, nicht um Mono

burli hat geschrieben:Unten drunter steht

Eigentlich steht das erst da, wenn man die Sprachen-Reihenfolge vertauscht.

Und auf der Hauptseite steht: """Python IronPython scripting for .net (mono is not ms .net) """. Anders wäre das ja auch seltsam, .NET auf Wine auf Gentoo für den Benchmark nutzen? Noch dazu das Mono tatsächlich manchmal diese Versionsnummer ausgibt.

Für den zitierten Benchmark gilt wahrscheinlich auch die allgemeine Regel: "Traue keinem Benchmark, den du nicht selbst gefälscht hast" ;)

Zu Beginn des IronPython-Projekts wurde verbreitet (und nicht dementiert), dass IronPython (Version 1) messbar schneller als CPython (Version 2.4) war (Faktor 1,3 bis 1,7 wurde genannt). Ich denke nicht, dass IronPython langsamer geworden ist. Und ob CPython 2.5 so viel schneller als 2.4 ist, bezweifel ich ebenfalls. Definitiv gilt, dass IronPython unter Microsofts .NET entwickelt und getestet wurde und das diese Version signifikant schneller ist als Mono. Aktuell ist zudem IronPython (2.0 beta 3), welches wahrscheinlich nochmals schneller ist als IronPython 1.1 - jedenfalls unter Microsofts .NET VM. Für irgendwas müssen ihre CallSite-Objekte (die polymophic inline caches implementieren, die derzeit beste Technik, um dynamische Methodensuche zu beschleunigen) der DLR doch gut sein...

Ich habe auf die Schnelle leider keinen anderen Benchmark gefunden, der die Versionen unter Windows und nicht unter Linux (mit Mono .NET) vergleicht. Ich vermute aber, da sieht das anders aus. Auch ist bestimmt nochmal die Mono-Version entscheidend, da auch hier die VM kontinuierlich besser wird.

Das sich IronPython die Performance mit höherem Speicheraufwand erkauft, sollte klar sein. Ebenso wird die Startzeit bedingt durch die VM-Technologie größer sein - beides ist aber für viele Anwendungen egal, da es dort um länger laufende Prozesse gibt, wo man Speicher und Startzeit gerne gegen zusätzliche Performance tauscht.

Ansonsten hätte ich die Hoffnung, dass wenn man die gleichen Optimierungen, die IronPython macht, für Jython und die Java-VM portiert und so die deutlich besseren Optimierungen der Hotspot-VM gegenüber Microsofts .NET VM nutzen kann, ein wirklich schnelleres Python erreicht - ähnlich wie JRuby inzwischen auch schneller als Ruby ist. Letzteres ist aber vielleicht auch wiederum nicht so schwer, trägt doch Ruby voller Stolz das Schlusslicht bei der Performance von Scriptsprachen :)

Stefan