Umfrage: Meistverwendete Python-Module?

ebeb · Dienstag 6. Oktober 2009, 13:32

Stefan, danke für die Antwort!

Ja, ich kenne diese Probleme. PyMite unterstützt ja leider (noch) keine Klassen. Deswegen ist auch ein Teil meiner Arbeit, zu schauen, wieviel aufwand es macht, die CPython Klassenimplemeniterung zu portieren und welche Auswirkungen es evtl auf schon portieren PyMite Code haben könnte.

Das sind insgesamt sehr viele Wenns und Wies die nicht so einfach beantwortet werden können.

Allerding hat das ganz für uns einen riesen Vorteil:
- Python is einfach
- Python wird gut supportet
- Einige unserer Zielplattformen unterstützten schon Python, und nur Python (keine C programmierung möglich)

Ich will mich damit nicht um Java drücken, und ehrlich gesagt ist mir Java auch lieber.

Wenn ich alles nativ machen würde und unsere Haupt-Zielplattformen biedenen will, müsste ich unser Framework in C, Python und Java schreiben!!! da lässt sich sicherlich einiges per Code-gerator machen, aber schon allein die Wartung und Tests erzeugen über Jahre Aufwand.

Wenn man aber Python portieren würde (das braucht man nur in C und Java zu tun), dann würde man sich für die Zukunf SEHR viel Zeit und damit Geld sparen.

ebeb · Dienstag 6. Oktober 2009, 13:54

Hmm...Es sieht wirklich so aus, als würde PyPy genau das richtige sein.

Es unterstütz schon out-of-the-box die Möglichkeit, den Interpreter in C, CIT und für die JVM zu übersetzten.

Allerdings steht auf einer der Doc pages:

PyPy's Python interpreter can be translated to Java bytecode now to produce a pypy-jvm. At the moment there is no integration with Java libraries yet, so this is not really useful.

Da ist mir nicht ganz klar, was das heißen soll. Wozu brauche ich Java-Libs wenn der PYthon Interpreter läuft. Dann kann ich doch Py-Libs nehmen? Oder meinen die, dass damit die Plattformabhängigen APIs nicht zur Verfügung stehen...!?

Zum Thema Python module/libs folgendes:

More of CPython's standard library extension modules are supported, among them ctypes, sqlite3, csv, and many more. Most of these extension modules are fully supported under Windows as well.

und

We have tested PyPy with a number of third-party libraries. PyPy can run now: Django, Pylons, BitTorrent, Twisted, SymPy, Pyglet, Nevow, Pinax:

Ich kenne die Libs zwar nicht, aber es lässt zumindest hoffen, dass somit auch andere Libs laufen werden.

sma · Dienstag 6. Oktober 2009, 20:29

ebeb hat geschrieben:Ja, ich kenne diese Probleme. PyMite unterstützt ja leider (noch) keine Klassen. Deswegen ist auch ein Teil meiner Arbeit, zu schauen, wieviel aufwand es macht, die CPython Klassenimplemeniterung zu portieren und welche Auswirkungen es evtl auf schon portieren PyMite Code haben könnte.

Ich kannte PyMite nicht. Offenbar eine VM für Python-Bytecode. Auch so etwas habe ich schon mal so weit getrieben, bis ich an Generatoren verzweifelt bin. Ist hier irgendwo im Forum unter dem Stichwort "Continuations" nachzulesen. Auch wenn's nicht offiziell dokumentiert ist, kann ich das Format von pyc-Dateien in Java einlesen und dann anfangen zu interpretieren.

Pi*Daumen würde ich sagen, Klassen machen den Interpreter etwa 10x komplizierter. Und ich würde empfehlen, entweder Python 1.x nur mit oldstyle-Klassen oder Python 3.x nur mit newstyle-Klassen zu implementieren. Für Python 1.x würde ich sagen, das ganze wird nur 4x komplizierter. Da fehlt die gesamte Metaebene.

- Python is einfach

Dem würde ich widersprechen. Vorteil von Python (z.B. gegenüber von Ruby) ist, dass es eine akkurate schriftliche Spezifikation gibt. Auch ist der Parser im Vergleich zu Ruby viel einfacher.

Doch es gibt Sprachen, die viel einfacher sind als Python. An eurer Stelle würde ich mir einmal Lua anschauen. Tipps für diverse exotischere Sprachen spare ich mir mal ;)

Stefan

sma · Dienstag 6. Oktober 2009, 20:31

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:

Code: Alles auswählen

    def fac(n):
        return 1 if n == 0 else n * fac(n - 1)
    
    print fac(10)

Code: Alles auswählen

    public class Script {
        public static final PyInteger zero = new PyInteger(0);
        public static final PyInteger one = new PyInteger(1);
        public static Python python = new Python() {
            public PyObject fac(PyObject n) {
                return n.eq(zero).truth() ? one : n.mul(fac(n.sub(one)));
            }
        };
        public static void main(String[] args) {
            python.print(python.fac(new PyInteger(10)));
        }
    }

Meine Messungen (allerdings mit JIT) haben gezeigt, dass es besser ist, direkt mit Integer und String statt mit eigenen PyInteger und PyString-Objekten zu arbeiten, auch wenn das bedeutet, dass man nicht mehr Methoden benutzen kann:

Code: Alles auswählen

    public class Script {
        public static final Object zero = Integer.valueOf(0);
        public static final Object one = Integer.valueOf(1);
        public static Python python = new Python() {
            public Object fac(Object n) {
                return $truth($eq(zero, n)) ? one : $mul(n, fac($sub(n, one)));
            }
        };
        public static void main(String[] args) {
            python.print(python.fac(Integer.valueOf(10)));
        }
    }

In meinem speziellen Fall könnte ein Compiler statisch ermitteln, dass man "int" benutzen kann, falls die Sprache im Gegensatz zu "richtigem" Python keine Zahlen beliebiger Genauigkeit kennt. Dann muss man aber anfangen, mehrere Versionen der jeweiligen Methoden zu generieren und das wird dann auch schnell kompliziert.

Wie das Laufzeitsystem, das sich in der Klasse Python versteckt, aussieht, sollte klar sein. Falls nicht, hier ist es für den zweiten Fall:

Code: Alles auswählen

    public abstract class Python {
        Object $eq(Object a, Object b) {
            return $bool(a == null ? b == null : a.equals(b));
        }
        
        Object $mul(Object a, Object b) {
            if (a instanceof Integer) {
                if (b instanceof Integer) {
                    return Integer.valueOf(((Integer) a) * ((Integer) b));
                } else if (b instanceof String) {
                    return $mul((String) b, (Integer) a);
                }
            } else if (a instanceof String) {
                if (b instanceof Integer) {
                    return $mul((String) a, (Integer) b);
                }
            }
            throw new ValueError();
        }
        
        Object $mul(String a, int b) {
            if (b < 1) {
                return "";
            }
            if (b == 1 || a.length() == 0) {
                return a;
            }
            StringBuilder sb = new StringBuilder(a.length() * b);
            while (--b >= 0) {
                sb.append(a);
            }
            return sb.toString();
        }
    }

Dieser Ansatz funktioniert, solange mit keine speziellen "__"-Methoden oder Metaklassen benutzen will und auch nicht zulässt, dass man andere Formen der Introspection nutzt, wie etwa die Namen der Parameter einer Funktion herausfinden zu wollen oder das Dict mit den lokalen Variablen.

Vorteil dieses Ansatz: Man kann so ein Java-Gerüst mit wenig Aufwand in Python aus einem AST erzeugen. Das macht dann Spaß, damit zu experimentieren, solange jedenfalls, wie man nicht wie ich dann frustriert ist, weil es damit unmöglich* ist, Generatoren zu implementieren.

Stefan

* Ohne Threads oder massiv-invasive Eingriffe in den Bytecode

sma · Dienstag 6. Oktober 2009, 20:33

ebeb hat geschrieben:Hmm...Es sieht wirklich so aus, als würde PyPy genau das richtige sein.

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

Stefan

ebeb · Mittwoch 7. Oktober 2009, 07:37

@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

sma · Mittwoch 7. Oktober 2009, 09:01

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?

Code: Alles auswählen

def a():
    x = 1
    del x
    try:
        print x
    except:
        raise StopIteration
    finally:
        yield 4
    yield x
    
for x in a():
    print x

Normale Programme treffen diese Randbereiche nicht, aber zu einem vollständigen Interpreter gehört das dazu und kostet 90% der Zeit.

Stefan

ebeb · Mittwoch 7. Oktober 2009, 09:22

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

ebeb · Mittwoch 7. Oktober 2009, 13:21

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

sma · Mittwoch 7. Oktober 2009, 13:47

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

ebeb · Mittwoch 7. Oktober 2009, 13:56

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.