Python to C Converter

[burli]

Ich suche nach einer Möglichkeit, ein Python Programm in C Sourcecode umzuwandeln. Ich weiß, dass es nicht ganz trivial ist, aber ich versuche es trotzdem mal

Gefunden habe ich bisher nur ein Paper auf python.org und dieses Script

Dieses 211 Programm aus dem Paper habe ich nicht finden können und aus dem Script werde ich noch nicht richtig schlau. Es erzeugt zwar einen C Code, will aber ein Python.h includen, welches nicht existiert.

Gibt es vielleicht etwas aktuelleres? Kennt jemand eine andere Möglichkeit?

Der C Code soll anschließend selbstständig lauffähig sein. Um genau zu sein möchte ich den Code anschließend auf einem Mikrocontroller ausführen.

[Hyperion]

Es würde mich stark wundern, wenn es da eine gute und praktikable Möglichkeit gäbe. Ohne es genauer erklären zu können ist wohl das mächtige Objekt-Modell von Python "schuld" daran.

Ich denke hier werden so einige sich herausgefordert fühlen, das zu erklären oder auf eine Erklärung hier im Forum zu verweisen, die ich auf die schnelle nicht finden konnte (iirc hatten wir das Thema aber bestimmt schon mal). Ich vermute mal stark, dass sma dazu etwas auf Lager hat.

Der gangbare Weg dürfte eben sein, einen Interpreter auf den Controller zu pflantschen.

[DasIch]

Ohne den halben Interpreter mit in den C Code zu packen wird dass nicht gehen. Da muss man auf sowas wie RPython oder Cython zurückgreifen.

[burli]

d.H., die erzeugten C Codes benötigen trotz allem den Python Interpreter oder werden sogar mit ihm verlinkt? Das ist natürlich nicht ganz das, was ich möchte. Ein kompletter Interpreter passt allerdings nicht in den Controller

[Hyperion]

d.H., die erzeugten C Codes benötigen trotz allem den Python Interpreter oder werden sogar mit ihm verlinkt? Das ist natürlich nicht ganz das, was ich möchte. Ein kompletter Interpreter passt allerdings nicht in den Controller

Nein, Du brauchst schon den kompletten Interpreter, der dann eben den Byte-Code ausführt. Wenn das für den Controller zu groß wird, dann fürchte ich, dass es so nicht gehen wird und Du auf eine andere Sprache zurückgreifen musst.

[DasIch]

Ein kompletter Interpreter passt allerdings nicht in den Controller

Deswegen solltest du auch direkt C nutzen.

[burli]

Nein, Du brauchst schon den kompletten Interpreter, der dann eben den Byte-Code ausführt. Wenn das für den Controller zu groß wird, dann fürchte ich, dass es so nicht gehen wird und Du auf eine andere Sprache zurückgreifen musst.

Der Witz an dem in dem Paper beschriebenen 211 Programm ist ja gerade, aus dem Bytecode einen C Sourcecode zu generieren. Die Frage ist jetzt nur, wie viel "Python" noch nötig ist, damit der C Code läuft.

Das Script scheint ähnlich vorzugehen. Es compiliert zuerst die Python Datei und scheint den Bytecode in C umzuwandeln, einschließlich Klassen. Ich weiß nur nicht, was alles nötig ist, damit man das compilieren kann.

[LanX]

ich kenne das Thema aus Perl boards, das Hauptproblem ist die dynamische Typisierung von Scriptsprachen.

Will man z.B. im erzeugten C-code jedesmal erst dynamisch abchecken, ob es sich gerade um ein Integer oder String handelt um eine Fallunterscheidung zu fahren, bläht das den Code extrem auf und ist nicht mehr schneller als vorher.

Und den integrierten Interpreter braucht man spätestens wenn man auch sowas wie

Code: Alles auswählen

eval

unterstützen will...

[Hyperion]

Nein, Du brauchst schon den kompletten Interpreter, der dann eben den Byte-Code ausführt. Wenn das für den Controller zu groß wird, dann fürchte ich, dass es so nicht gehen wird und Du auf eine andere Sprache zurückgreifen musst.

Der Witz an dem in dem Paper beschriebenen 211 Programm ist ja gerade, aus dem Bytecode einen C Sourcecode zu generieren. Die Frage ist jetzt nur, wie viel "Python" noch nötig ist, damit der C Code läuft.

Das Script scheint ähnlich vorzugehen. Es compiliert zuerst die Python Datei und scheint den Bytecode in C umzuwandeln, einschließlich Klassen. Ich weiß nur nicht, was alles nötig ist, damit man das compilieren kann.

Ohne mir das genau angeguckt zu haben: Ich kann mir nicht vorstellen, dass das mit dem kompletten Sprachumfang von Python geht. Ansonsten wären Geschwindigkeitsprobleme ja quasi obsolet, da ich einfach meine Python-Funktion nur kurz kompilieren müßte und sie dann wieder in Python nutzen könnte.

Ich finde jetzt leider auch nichts brauchbares dazu, aber ich denke der ein oder andere unserer Experten wird hier schon noch reinschauen und dazu etwas fundierteres sagen können.

Das Script ist sehr alt; alleine das sollte doch zu denken geben. Ich kann mir einfach nicht vorstellen, dass niemand auf die Idee gekommen sein soll, das ganze weiter zu entwickeln und einen optionalen Python2C Compiler anzubieten. Natürlich bin ich hier weder empirisch noch systematisch vorgegangen, aber alles an Recherche meinerseits deutet das an. Wenn es so etwas gäbe, würde man es mit < 5 Minuten Suchaufwand sicherlich finden

[burli]

Gut, dann wäre es die einzige Möglichkeit, einen Compiler zu schreiben, der nur ein Subset der Python Syntax verwendet und auf dynamische Typisierung verzichtet. Auch nicht gerade das, was ich wollte.

[Hyperion]

Da hätte man auch mal sofort reingucken können:
http://wiki.python-forum.de/FAQ#Wo_gibt ... ompiler.3F

[LanX]

ich kenne das Thema aus Perl boards, das Hauptproblem ist die dynamische Typisierung von Scriptsprachen.

hab noch mal recherchiert, deswegen erlaubt cython statisches typing

siehe Faster code via static typing

[burli]

@DasIch: ach Cython. Ich hab gedacht CPython. Mal anschauen, wie das funktioniert

[LanX]

Gut, dann wäre es die einzige Möglichkeit, einen Compiler zu schreiben, der nur ein Subset der Python Syntax verwendet und auf dynamische Typisierung verzichtet. Auch nicht gerade das, was ich wollte.

ich denke du solltest dir cython anschauen, der Trick ist aus Performancegründen nur die inneren Schleifen statisch zu typen. Ob in der Initialisierung Microsekunden wg dynamischer Variablen verloren gehen ist kaum zu messen.

Aber IIRC ist cython für embedding von C-Code in Pythonskripten gedacht und nicht um stand-alone code zu erzeugen, lasse mich aber gerne korrigieren.

[DasIch]

Aber IIRC ist cython für embedding von C-Code in Pythonskripten gedacht und nicht um stand-alone code zu erzeugen, lasse mich aber gerne korrigieren.

Cython ist eigentlich dafür gedacht C-Extensions zu programmieren aber prinzipiell sollte es alles bieten was man braucht.

[burli]

Oha, Cython macht aus einer Zeile Python Code etwa 1000 Zeilen C Code.

[Darii]

ich kenne das Thema aus Perl boards, das Hauptproblem ist die dynamische Typisierung von Scriptsprachen.

Die dynamische Typisierung an sich ist da eher das kleinere Problem. Problematisch ist eher Python selbst. Das ist selbst einfach zu dynamisch, so dass ein Attributzugriff zwangsläufig immer ziemlich teuer ist.

Grundsätzlich kriegt man dynamische Typisierung recht schnell hin, wenn die Typen zur Laufzeit konstant sind und nicht alles über Dictionaries laufen muss. Siehe Objective-C. Die Sprachimplementierung war anfangs auch nur einen Präprozessor der C ausspuckt. ObjC ist auch dynamisch typisiert, die Methodenaufrufe sind aber nur etwas langsam als virtuelle C++-Methodenaufrufe wenn ich mich richtig erinnere.

Aber das ist eine andere Sprache, bei Python muss man quasi immer den kompletten Interpreter mitschleppen. Das einzige was da noch hilft ist eine Laufzeitumgebung, wie die die von PyPy erzeugt wird, die in der Lage ist optimierten Code auszuspucken. Das ist aber auch nur möglich, weil man die Dynamik von Python in 99% der Fälle eh nicht braucht.

@burli: Wenn dann musst du schon das statisch typisierte Cython nehmen, das ist nur C mit anderer Syntax.

[burli]

Siehe Objective-C. Die Sprachimplementierung war anfangs auch nur einen Präprozessor der C ausspuckt.

Gibt es das noch? Wäre auch interessant.

[burli]

@burli: Wenn dann musst du schon das statisch typisierte Cython nehmen, das ist nur C mit anderer Syntax.

Ich hätte es eher mit Pascal verglichen

[Darii]

Gibt es das noch? Wäre auch interessant.

Ja und der Marktanteil steigt kontinuiertlich (Sprache der Wahl von Apple). Allerdings hat das inzwischen auch einen richtigen eigenen Compiler und ist kein Präprozessor mehr. Wie die Linux/Windows-Situations aussieht weiß ich nicht genau. GNUstep wird wohl zur Zeit tatsächlich aktiv weiterentwickelt (http://etoileos.com ist ein recht ambitioniertes Projekt) aber afaik muss man sich da wirklich den trunk selbst compilieren, wenn man eine aktuelle Version haben will.

Ich finds schade, dass das nie so wirklich was geworden ist, hätte wirklich was werden können. Und verstehen tu ich es noch weniger, stattdessen gabs GNOME und GObject.