Umfrage: Meistverwendete Python-Module?

[ebeb]

Servus und Hallo ans Forum!

Meine Frage ist etwas komplexer und ließ sich nicht auf die Titel-Zeile begrenzen, deswegen hier nochmal die Frage im Detail:
Ich würde gerne Wissen, welche Module im täglichen Gebrauch mit Python am häufigsten verwendet werden.

Warum frage ich das? Weil ich momentan evaluiere, ob es sich lohnt, Python (Im speziellen den Interpreter samt nötigen Libs) auf Java zu portieren. Ich entwickle u.a. Systeme für mobile Anwedungen auf verschiedensten Plattformen und Python ist da eine sehr attraktive Alternative zur nativen Programmierung. Insbesondere wenn man nur ein Framework schreiben muss und das auf verschieden Plattformen laufen lassen kann.

Ich habe auch schon als Proof-of-concept den Bytecode-Interpreter auf Java ME portiert und zum laufen gebracht (Es lassen sich einfach vorcompilierte Python-Scripte auf einer Java ME umgebung ausführen).

Ich bin gerade bei der Aufwandsschätzung und dabei ist mir aufgefallen, dass einige Module in C geschrieben sind (_socket, _sre...). Die müsste ich dann auch portieren. Ich hatte eigentlich gehofft, dass der Großteil der Python Module auch in Python und nicht in C geschireben sind.

Um meine Frage noch zu verdeutlichen, ich bin mit Python noch nicht vertraut genug, dass ich weiß, was man in der Praxis benötig (besonders in Bezug auf Kommunikation, Sockets, XML, Strings parsen, Dateizugriffe).

Deswegen die Frage. Wenn ihr also aus der Erfahrung ein paar Module nennen könntet, die ihr immer importiert, kann ich den Aufwand besser einschätzen, den es ergeben würde, wenn wir diese unterstützden würden. Denn meist importieren Python module wiederum diese in C geschireben "_"-Module.

Vielen Dank und Gruß Jan

[Hyperion]

Inwiefern unterscheidet sich Dein Projekt von Jython?

[CM]

Hallo und willkommen im Forum,

Willst Du das Rad neu erfinden?

Abgesehen davon führt die Frage nach den meistverwendeten Modulen in die Irre: Reine Python-Module müssten sich ja ohne Weiteres in Deinem Java-Python ausführen lassen. Problematisch sind wohl Module auf C/C++/Fortran-Basis.

Meinereiner macht eher wissenschaftliches Rechnen und da gibt es einige interessante Entwicklungen, die Du auf den Konferenzseiten ([1] und [2]) erschliessen kannst. Und einige davon beissen sich so sehr mit dem bisherigen Interpreterkonzepten, dass es unklar ist, in welche Richtung die Community steuert.

HTH,
Christian

edit: Zu langsam ...

[ebeb]

Ja, Jython kenne ich, nur leider das funktioniert nicht. Jython erstellt Java Code aus Python skripten. Das ist ein ganz anderer Ansatz. Was ich für vielversprechend hielt, ist der Jython Compiler der Java Byte Code / class files erzeugt. Wird aber seit X Versionen niht mehr gepflegt. Darüber hinaus benötige ich unterstützung für Java ME (IMP, MIDP). Einige wenige Foreneinträge gibt es, in der Leute versucht haben, das ganze für Java ME zum laufen zu kriegen. Ohne Erfolg.

Da ich nicht nur Java Platformen, sondern auch C plattformen unterstützen muss, habe ich PyMite als Grundlage für den Java-Port genommen. Dort stellt sich dann die gleiche Frage nach den Modulen, da diese auch nicht implementiert sind.

PyMite deshalb, weil ich 8-Bitter unterstützden muss.

gruß jan

Ps: Ich bin trotzdem über jede Idee dankbar, die mir das Leben leichter machen könnte

[Rebecca]

Nicht dass ich mich gross damit auskennen wuerde, aber was ist mit pypy?

[BlackJack]

@ebeb: Ist es denn überhaupt so relevant, was die Leute auf Desktop-Rechnern für Module benutzen? Ich würde mal sagen auf Java ME-Plattformen würden andere Applikationen geschrieben, oder?

Ansonsten wär's bei mir wohl `itertools`, `functools`, und `operator`, was ich nahezu unabhängig vom Programm importiere. Ob ich das auch auf einem 8-Bitter machen würde!?

[ebeb]

@BlackJack:

Naja...es gibt zwei Möglichkeiten. Wenn wir selbst das Framework samt Anwednungen entwickeln, lässt sich das Risiko minimieren, da man ja weiß was unterstützt wird und was nicht.

Das Problem kommt aber dann, wenn ein Kunde selbst Anwendungen für unser Python-Framework entwickeln möchte. Dann könnte es passieren, dass Kunde XY unbeding das modul ABC benutzen möchte.
Ich versuche nur im Vorfeld abzuklären, ob es Sinn macht, eine Art Untermenge zu bilden, die eine möglichst geringe Anzahl von Nativen-C-Modulen enthält die wiederum eine möglichst große Anzahl von reinen Python-Modulen abdeckt.

@Rebecca:
danke für den Hinweis. PyPy kannte ich inder Tat nicht. Allerdings ist mir der Sinn noch nicht so klar. Ein in python geschriebener Python Interpreter? Ich sehe da den Vorteil noch nicht so ganz. Gerade in Bezug auf die be CPython in C geschiebenen Module, sind die dort komplett unterstützt und in Python geschrieben? So wie ich das beim überfliegen sehen konnte, wird auch nur eine Untermenge (Restricted Python) von Pyhon unterstützt. Aber da lasse ich mich gern belehren!

Aber dann stellt sich auch irgendwann die Performance-Frage:
ARM-Core -> In c geschriebene JVM -> IN java geschriebener minimal Python Interpreter -> in Python geschriebener Python-Interpreter -> Python Applikationen

da habe ich große Zweifel

[Leonidas]

Die müsste ich dann auch portieren. Ich hatte eigentlich gehofft, dass der Großteil der Python Module auch in Python und nicht in C geschireben sind.

Und wenn sie in Python geschrieben wären, wie würdest du auf die Funktionalität des OS und der libc zugreifen wollen? Etwa über dl/libffi? Dann muss immerhin das libffi-Binding in C geschrieben sein.

Persönlich nutze ich am meisten ``sys``, weil es sowieso immer importiert wird.

[Pekh]

@Rebecca:
danke für den Hinweis. PyPy kannte ich inder Tat nicht. Allerdings ist mir der Sinn noch nicht so klar. Ein in python geschriebener Python Interpreter? [ ... ]
Aber dann stellt sich auch irgendwann die Performance-Frage:
ARM-Core -> In c geschriebene JVM -> IN java geschriebener minimal Python Interpreter -> in Python geschriebener Python-Interpreter -> Python Applikationen

da habe ich große Zweifel

Ich tue mich mit dem Gedanken auch noch so ein wenig schwer, aber es geht wohl darum, eine Engine zu entwickeln, die beliebige Interpreter erzeugen kann. Also zum Beispiel einen auf Java-Basis. Die Anwendungen laufen dann direkt auf dem erzeugten Interpreter. Es gab da mal ein Video-Interview von einigen der Entwickler dazu, dem ich das so entnommen habe.

[ebeb]

@Leonidas
Naja...die bytecodes bzw. builtin funktionen sind ja letztendlich schon das interface zum Betriebsystem. ich hatte gehofft, dass zum bsp. sockets einfach als eine Art streams behandelt wird. Das man praktisch einfach inen open(...) zugriff macht und fertig. Stattdessen gibt es eine socket.py die wiederum das in C geschriebene _socket importiert was dann auf die OS API zugreif.

Und auch die Regex...es gibt eine sre, die dann das in C geschriebene _sre importiert. Und das muss nun wirklich nicht sein.

Aber da hat man sich im Spagat zwischen Plattformunabhängigkeit und Performance für die Performance entschieden was mir jetzt leider Probleme bereitet.
@Pekh, rebecca:
Ich hab mir das mal ein wenig durchgelesen. Es sieht so aus, als müsste man nur ein paar Objekte native abbilden, und dann schmeisst man das ganze in die Toolchain und am Ende wird ein Interpreter ausgespuckt. Hört sich erst mal gut an, aber glauben tue ich das noch nicht. Besonders eben ob der daraus entstehende Interpreter alle Bibliotheken unterstützt oder eben nur reine Python libs!?

[Leonidas]

Naja...die bytecodes bzw. builtin funktionen sind ja letztendlich schon das interface zum Betriebsystem. ich hatte gehofft, dass zum bsp. sockets einfach als eine Art streams behandelt wird. Das man praktisch einfach inen open(...) zugriff macht und fertig.

Aber nichtmal auf Unix sind sockets über Dateien erreichbar, also kannst du kein ``open()`` machen, weil du keine Datei zum öffnen hast. Sowas geht afair nur unter Plan 9, und es würde mich wundern wenn Symbian so etwas bieten würde. Zudem ist ``open()`` auch wieder eine Funktion aus der libc, wie soll man ohne C-Code darauf zugreifen?

Stattdessen gibt es eine socket.py die wiederum das in C geschriebene _socket importiert was dann auf die OS API zugreif.

Klar, weils halt BSD sockets sind.

Und auch die Regex...es gibt eine sre, die dann das in C geschriebene _sre importiert. Und das muss nun wirklich nicht sein.

Schon mal die Performance einer Statemachine in Python gesehen?

Aber da hat man sich im Spagat zwischen Plattformunabhängigkeit und Performance für die Performance entschieden was mir jetzt leider Probleme bereitet.

Da es aber ANSI C ist, ist es doch ziemlich portabel, wie etwa PyS60 beweist.

[lunar]

@ebeb: Eine Abhängigkeit zur Systemschnittstelle verschwindet nicht einfach, wenn man ihr einen anderen Namen gibt. Wenn man Sockets innerhalb von "open()" implementiert hätte, wäre die C-Implementierung halt in "__builtin__" anstatt in "_socket". Portieren müsstest Du sie so oder so.

Reguläre Ausdrücke dagegen wären zu langsam gewesen, wenn man sie in Python implementiert hätte. Und da Standard-C für Pythons Zwecke portabel genug ist, besteht eigentlich kein Anlass zur Änderung.

[ebeb]

Aber nichtmal auf Unix sind sockets über Dateien erreichbar, also kannst du kein ``open()`` machen, weil du keine Datei zum öffnen hast. Sowas geht afair nur unter Plan 9, und es würde mich wundern wenn Symbian so etwas bieten würde. Zudem ist ``open()`` auch wieder eine Funktion aus der libc, wie soll man ohne C-Code darauf zugreifen?

Ich meinte die open builtin python funktion. Die ist, ja, in C geschrieben. Aber die builtins hätte ich sowieso portieren können. Deswegen hätte man die socket implementieren auch über sowas abbilden können. Aber warscheinlich bleiben dann zuviele funktionen der API auf der strecke.

Da es aber ANSI C ist, ist es doch ziemlich portabel, wie etwa PyS60 beweist.

Ja, klar, wenn ich ein ARM7/9 hätte den ich direkt Programmieren könnte, würde ich auch einfach das ganze CPython nutzen. Ich hatte mir auch schon den Sourcecode von PyS60 angeschaut. Aber soviel power steht leider nicht zur Verfügung. D.h. ich muss mich auf den Interpreter beschränken.

Schon mal die Performance einer Statemachine in Python gesehen?

Nein. Über ein Hello World und ein paar schleifen und Funktionen zum testen des Java-Python Interpreters bin ich noch nicht hinaus gekommen.

[jens]

Zum Thema PyPy: [wiki]FAQ#Was ist PyPy.3F[/wiki] und [wiki]PyPy[/wiki]

Neben "sys" ist "os" noch sehr wichtig, denke ich...

[sma]

Spannendes Thema. Könnte ich viel zu schreiben :) Habe selbst schon 2x einen unvollständige Python-Interpreter in Java (so just for fun) gebaut.

Ich halte jedoch die Ziele "Compiler für Java ME" und "Python-Semantik" nicht für vereinbar. Du kannst ein Java mit Python-Syntax haben oder einen Python-Simulator für die JVM. Beides ist nahezu unmöglich und ein Grund, warum es die Jython-Jungs so schwer haben, das Projekt seit Jahren kaum voran kommt und der Quelltext auch nicht gerade die beste Qualität hat.

Wenn's dir nur um die Syntax geht, warum nicht z.B. Scala? Oder - das ist zwar nicht Python-ähnlich, aber einfacher als Java - JavaFX?

Die Frage ist immer, was bezeichnet man als Python? Sprich: Welche Semantik will man unterstützen? Da Python so dynamisch ist, stößt man schnell entweder an Grenzen (und hat wieder nur den Syntax-Aspekt) oder aber es wird unerträglich langsam - gerade im Java ME Umfeld, wo man nicht davon ausgehen kann, das man einen guten JIT hat.

Schauen wir, was bei foo.bar(a, b) passieren muss:

Suche nach "foo" im passenden Frame. In bestimmten Fällen ist nicht klar, ob foo eine lokale oder eine globale Variable ist, dann muss man nacheinander suchen. Und wenn es keine globale Variable ist, dann ist da immer noch das __builtins__-Modul. Das sind also schon bis zu drei Lookups in einem Dict. Man beachte, dass man mit "del" lokale Variablen aus dem aktuellen Frame löschen kann. Das lässt sich so nicht direkt auf lokale Variablen in der JVM abbilden. Nun habe ich ein Objekt. Dort muss ich mit getattr nach "bar" suchen können. Ist es ein Exemplar einer Klasse, hat es ein __dict__. Vielleicht finde ich dort etwas. Ansonsten schaue ich mal im __dict__ der Klasse. Auch nix? Dann muss ich die Oberklassen gemäß C3 serialisieren und diese Liste abklappern und in jedem __dict__ suchen. Immer noch nix? Dann mache ich mich in der Klasse und allen Oberklassen auf die Suche nach __getattr__ (und die Behandlung von __getattribute__ habe ich dabei noch vergessen). Wenn ich immer noch nix gefunden habe, muss ich eine Python-Exception bauen und werfen. Dafür muss ich jetzt einen Traceback mit Frame-Objekten zusammenstellen. Schließlich könnte jemand das Ding inspizieren wollen. Ansonsten habe ich ein Objekt, das callable sein muss. Halt nein, es kann auch ein Decorator sein. Suche ich also nach __get__ in der Klasse des Objekts und allen Oberklassen. Wenn vorhanden, rufe ich das auf - wie das geht, siehe später - der Prozess ist gehirnverknotend rekursiv. Für a und b mache ich das selbe wie für foo. Dann baue ich daraus ein Tupel. Mit diesem Tupel (und einem leeren Dict für die nicht vorhandenen Schlüsselwortargumente) rufe ich jetzt __call__ auf. Das muss ich natürlich finden und wieder laufe ich auf der Suche nach einer Methode über die Klassenhierarchie, die ich zuvor wieder serialisieren muss - jedenfalls bei newstyle-Classes. Oldstyle macht es einfacher. Doof nur, dass man beides auch in Kombination bedenken muss. Nun habe ich Meine Funktion und meine Argumente. Diese muss ich jetzt auf die Parameter abbilden. Zunächst Positionsparameter. Habe ich Standardwerte? Diese stecken in func_defaults des Funktionsobjekts. Nach diesem Attribut muss ich wieder so suchen, wie ich das schon für foo gemacht habe. Wie häufig ich inzwischen in einem Dict nach einem Schlüssel gesucht habe, kann ich schon gar nicht mehr sagen. 20x? Dann muss ich noch die Schlüsselwortargumente verteilen. Es ist ein Fehler, wenn sich das mit einem Positionsparameter überlappt. Es ist auch ein Fehler, wenn man Schluss ein Positionsparameter ohne Standardwert unbelegt bleibt. Muss ich noch eine Restliste bauen? Was ist mit den verbliebenden Schlüsselwortargumenten? Ggf. muss ich diese noch zuweisen. Python 3 wird noch komplizierter, Details sind mir jedoch entfallen. Nun kann ich einen neuen Frame bauen, initialisieren und schon den Rumpf der Funktion ausführen.

Einige dieser Schritte kann man überspringen, aber Python ist so flexibel und dynamisch, dass man meist erst zur Laufzeit weiß, ob man's braucht. Ohne guten JIT, der dann Optimierungen durchführt, ist man in Java meines Erachtens nach verloren.

Was man machen kann, ist eine kleine Scriptsprache zu erfinden, deren Syntax wie die von Python ist, die aber ein radikal einfacheres Laufzeitsystem mit der Semantik von Java hat und optional statisch getypt ist. Aber das ist nicht Python.

Die Frage nach den Moduln stellt sich IMHO auch nicht so sehr, denn in der Regel halte ich die Java-APIs -- gerade wenn man mit Dingen wie MIDP und den ganzen für JSRs definierten APIs reden will, für besser designed. Python merkt man in der Standardbibliothek häufig sein Alter an.

Stefan

[ebeb]

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]

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]

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]

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]

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