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.
IronPython und Mono
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.bernd_Aachen hat geschrieben:- Hat jemand die Hürde schon einmal genommen und kann IronPython unter Mono auf Linux benutzen ?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Niveau sieht nur von unten aus wie Arroganz.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.flummox hat geschrieben:Boo rockt einfach wie Sau!
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 670
- Registriert: Sonntag 15. Januar 2006, 18:42
- Wohnort: Celle
- Kontaktdaten:
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.
--- Heiko.
Geschmaecker sind verschieden. Ich liebe Boo einfach.
Niveau sieht nur von unten aus wie Arroganz.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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).blackbird hat geschrieben:Eher. Warum will man ironpython verwenden?
Vergleiche Jython.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
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.Leonidas hat geschrieben: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).blackbird hat geschrieben:Eher. Warum will man ironpython verwenden?
TUFKAB – the user formerly known as blackbird
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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 dablackbird 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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.Leonidas hat geschrieben:blackbird hat geschrieben:IronPython ist auch schneller als CPython, zumindest wenn man den alten Benchmarks glaubt.
-
- User
- Beiträge: 5
- Registriert: Sonntag 12. März 2006, 09:05
- Wohnort: Aachen
@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.
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.
-
- User
- Beiträge: 670
- Registriert: Sonntag 15. Januar 2006, 18:42
- Wohnort: Celle
- Kontaktdaten:
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.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.
--- Heiko.
-
- User
- Beiträge: 5
- Registriert: Sonntag 12. März 2006, 09:05
- Wohnort: Aachen
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.
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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich denke dass dies schon unter Mono ist, wenn man davon ausgeht, dass es kein Windows Gentoo gibt.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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Eigentlich steht das erst da, wenn man die Sprachen-Reihenfolge vertauscht.burli hat geschrieben:Unten drunter steht
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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
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