Das deutsche Python-Forum

@Stefan: Zu post #1:

An eurer Stelle würde ich mir einmal Lua anschauen.

Wie gesagt, wir wollen u.a. Zielplattformen addressieren, die explizit nur Python unterstützen. D.h. wir müssten es dann sowieso ein Mal in Python implementieren. Oder wir müssten dann LUA in python implementieren.

zu #2:

Als ich Python-Compiler nach Java las, dachte ich, gemeint war ein System, was Python-Code nimmt und in äquivalenten Java-Code umwandelt (oder direkt Java-Bytecode erzeugt, was konzeptionell kaum einen Unterschied macht). Z.B. so:

Nein, war nicht gemeint

weil es damit unmöglich* ist, Generatoren zu implementieren.

Ja...nach dem ich mir mal durchgelesen habe was Generatoren sind, sehe ich da auch noch ein Problem. Auch in meinem momentanen Port von PyMite, da dort momentan nur eine flache Klassenhierarchie besteht, also quasi "gar keine".

Danke die für die Arbeit, allerdings bin ich mir nicht so ganz im klaren, was ich mit deinem Sourcecode anfangen soll Wie gesagt, ich möchte Python skripte nicht nach Java portieren Sondern mit Hilfe von Python die Portabilität unseres Frameworks für verschiedene Hard- Softwareplattformen gewährleisten.

zu #3:

Ich glaube nicht, dass ein mit PyPy generierter Python-Interpreter (selbst ohne JIT) in eines dieser embedded-Systeme passt.

Das ist ein wichtiger Einwand, den ich aber gerne Etwas detaillierter formuliert hätte. Ich sehe bei embedded Systemen besonders den Arbeitsspeicher als das zentrale Problem. Weder Ausführungsgeschwindigkeit noch der Flashspeicher sollte bei modernen MCUs ab 8-Bit ein Problem sein. Und es ist klar, dass ein full-featured Python Interpreter solch eine MCU schnell an die Grenzen bringen wird.

Allerdings ist PyPy laut den Entwickern u.a. mit dem Ziel gestartet worden, Python auf verschiedenen Embedded-Umgebungen laufen zu lassen. Allerdings weiß ich nicht wie weit da die Entwicklungen fortgeschritten sind. Es gibt aber soger ein Whitepaper das genau solche Embedded-Anwendungen mit PyPy beschreibt.

http://codespeak.net/pypy/extradoc/eu-r ... -03-26.pdf

Gruß Jan

Wenn's Python sein soll, dann hast du ja praktisch schon die Entscheidung getroffen. Offenbar ist ja auch die Performance zweitrangig für diese Entscheidung. Jetzt heißt es doch "nur" noch, das Subset von Python zu bestimmen, das du unterstützen willst.

Ich habe mit meinem Python-Simulator etwa 1/100 bis 1/20 der Performance von CPython erreicht - und das dank JIT. Der Memory-Footprint war mir egal, aber der ist garantiert größer als bei CPython. Das sieht für mich alles nicht nach einer idealen Plattform für embedded-Systeme aus.

Da kann ich aber überhaupt nicht abschätzen, wie viel die zu leisten vermögen. Ich kann mich nur an die Ära der Home-Computer erinnern, wo 8-Bit-CPUs Standard waren und 64 KB RAM plus vielleicht noch mal 16 oder 32 KB ROM das Höchste der Gefühle. Ich vermute aber, dass bereits die SIM-Karten von Telefonen mehr Leistung haben.

Reden wir bei dem Java von einem reinen Bytecode-Interpreter oder einem JIT. Oder versteht (wie beim ARM) der Prozessor selbst Java-Bytecodes?

Die Codebeispiele habe ich nur zur Erläuterung geschrieben, nicht weil ich glaube, dass sie nun genau dir helfen werden :)

Wir haben vielleicht auch unterschiedliche Vorstellungen, wie viel Python ein Python-Interpreter können muss. Soll dies gehen?
Normale Programme treffen diese Randbereiche nicht, aber zu einem vollständigen Interpreter gehört das dazu und kostet 90% der Zeit.

Stefan

Wenn's Python sein soll, dann hast du ja praktisch schon die Entscheidung getroffen. Offenbar ist ja auch die Performance zweitrangig für diese Entscheidung.

Naja...Die Entscheidung wie ich es genau machen werde ist noch nicht getroffen. Auch nicht ob ich es überhaupt so machen werde. Wenn der Aufwand zu groß wird bzw. da ganze aufgrund von Speichermangels nicht läuft, dann geht es eben nicht.

Die Performance sehe ich aber in der Tat nicht als so wichtig an. Die Java-Umgebung an sich ist schon nicht echtzeitfähig, also macht es dann auch nicht so den riesen unterschied wenn es statt 10ms 100 braucht. Wenn aber die einfachsten Dinge sekunden brauchen, dann geht es schon in die Richtung unbrauchbar. Das muss man dann eben mal testen.

Da kann ich aber überhaupt nicht abschätzen, wie viel die zu leisten vermögen. Ich kann mich nur an die Ära der Home-Computer erinnern, wo 8-Bit-CPUs Standard waren und 64 KB RAM plus vielleicht noch mal 16 oder 32 KB ROM das Höchste der Gefühle. Ich vermute aber, dass bereits die SIM-Karten von Telefonen mehr Leistung haben.

Naja...eine SIM-Karte vielleicht nicht gerade Und über 64kB RAM würde ich mich manchmal freuen. Meistens haben die 8-bitter MCUs 2-8kB RAM Nicht zu verwechseln mit Prozessoren in Computern, die "nur" rechnen und externes RAM haben!

PyMite läuft (ohne Klassen und Generatoren) übrigens mit unter 4kB RAM!!! Deswegen war ich mir sicher, dass es auch als Java-Embedded-Port laufen wird!

Allerdings sind die vorerst anvisierten Zielplattformen allesamt 32Bit ARM. Aber es könnte auch mal irgendwann ein 8 oder 16-Bitter sein.

Reden wir bei dem Java von einem reinen Bytecode-Interpreter oder einem JIT.

http://java.com/de/download/faq/what_kvm.xml

Ersteres!

Wir haben vielleicht auch unterschiedliche Vorstellungen, wie viel Python ein Python-Interpreter können muss. Soll dies gehen?

Schönes Beispiel. Da sind ne Menge Bytecodes enthalten, die PyMite momentan nicht unterstützt (finally, exceptions, yield...)

Ich muss dazu leider wieder sagen....ich kenne PYthon dazu zu wenig. Gerade bei yield hab ich ne Weile gesessen, bis ich überhaupt verstanden habe was das "tut".

Funktionen sollten gehen. Exceptions wäre auch von Vorteil. Und Klassen natürlich. Wenn ich jetzt anfange funktional zu programmieren, kann ich es gleich lassen.
Solcher vereinfachungen um Listen durchzugehen müssen nicht unbedingt sein.

Gruß Jan

Hmm...ich bin jetzt etwas "zerrissen". Ich habe gerade bemerkt, dass ich mit einer älteren Version von PyMite gearbeitet habe. Das ist jetzt in python-on-a-chip übergegangen.

Dort ist jetzt einiges hinzugekommen:
# 2009/09/07 (r372) New feature: The backtick operator (s=`x`) for integers and floats.
# 2009/09/06 (r371) New feature: String concatenation using +.
# 2009/06/15 Steve Holden of the PSF granted this project permission to include the official Python logo in a derived work for the Python-on-a-Chip logo (seen above, to the left of the project title).
# 2009/05/17 (r364) New feature: Generators with iterators, expressions and coroutines
# 2009/05/13 The first reference platform, http://www.mbed.org/ mbed] was delivered to 10 developers.
# 2009/04/28 (r356) New feature: Classes with multiple inheritance

D.h. Klassen sind jetzt unterstützt! Allerdings eben die ganzen Lib noch nicht. Ach und mit Generatoren kenn ich mich nicht aus, aber z.B. du, Stefan, wohl um so besser. Kannst du damit was anfangen, ob das jetzt komplett ist und was noch zu Generatoren fehlt?

Ich habe außerdem eine Antwort von den PyPy Entwicklern bekommen. PyPy erzeugt wirklich einen in Java "geschriebenen" RPython Interpreter auf dem dann ein weiterer Vollwertiger PYthon Interpreter läuft.

Das ganze hat dann als Jar-File so um die 10MB was natürlich auf einem embedded device mit eingeschränktem Umfang ein Unding ist. Vielleicht lässt sich da aber noch etwas abspecken.

Tendentiell würde ich aber jetzt wieder zu PyMite/Python-on-a-chip tendieren

Ich habe mal über die (etwas längere) Mittagspause einen Python-Bytecode-Interpreter gebaut, der "fib" berechnen kann: http://gist.github.com/204002

Würde so was auch unter Java ME laufen?

"Generators" klingt vollständig. Einfache Generatoren wurden für Python 2.5 um Features für Coroutinen erweitert. Wenn Python-on-a-chip das kann, sind die ganz weit vorne. Bei den Klassen mit Mehrfachvererbung wäre interessant zu wissen, ob das oldstyle oder newstyle-Klassen sind. Habe gerade mal in den Quelltext gespickt. Das sieht nach oldstyle aus. Zudem fehlt jede Unterstützung für all diese Spezialmethoden, die Python IMHO erst interessant machen, weil man dadurch eigene Datentypen bauen kann.

Stefan

Ich habe mal über die (etwas längere) Mittagspause einen Python-Bytecode-Interpreter gebaut, der "fib" berechnen kann:

LOL!! So ähnlich hab ich das meinen "Chefs" auch beigebracht, dass ich "nebenbei" Python für Java ME portiert habe und dass das doch sehr interessant wäre

Also, ja...ist generell lauffähig, nur dass es weder HashMap noch Map gibt. Müsste man dann auf Hastable ausweichen. Siehe MID API doc: http://java.sun.com/javame/reference/apis/jsr118/.

Ich denke ich werde jetzt die änderungen für Klassen und generatoren in meinen Javaport einbauen. Das erscheint mir erst mal als die sinnvollste Variante. Ich werd mal mit den Entwicklern reden, vielleicht kann man das ja als parallelen Zweig aufnehmen um das konsistent zu halten.