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.
Python to C Converter
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
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.
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.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
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
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
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.burli hat geschrieben: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
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
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.Hyperion hat geschrieben: 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.
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.
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
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 unterstützen will...
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
Zuletzt geändert von LanX am Freitag 23. Juli 2010, 12:33, insgesamt 1-mal geändert.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
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.burli hat geschrieben: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.Hyperion hat geschrieben: 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.
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.
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
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
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.
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Da hätte man auch mal sofort reingucken können:
http://wiki.python-forum.de/FAQ#Wo_gibt ... ompiler.3F
http://wiki.python-forum.de/FAQ#Wo_gibt ... ompiler.3F
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
hab noch mal recherchiert, deswegen erlaubt cython statisches typingLanX hat geschrieben:ich kenne das Thema aus Perl boards, das Hauptproblem ist die dynamische Typisierung von Scriptsprachen.
siehe Faster code via static typing
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.burli hat geschrieben: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.
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.LanX hat geschrieben: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.
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.LanX hat geschrieben:ich kenne das Thema aus Perl boards, das Hauptproblem ist die dynamische Typisierung von Scriptsprachen.
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.
Gibt es das noch? Wäre auch interessant.Darii hat geschrieben: Siehe Objective-C. Die Sprachimplementierung war anfangs auch nur einen Präprozessor der C ausspuckt.
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
Ich hätte es eher mit Pascal verglichenDarii hat geschrieben: @burli: Wenn dann musst du schon das statisch typisierte Cython nehmen, das ist nur C mit anderer Syntax.
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
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.burli hat geschrieben:Gibt es das noch? Wäre auch interessant.
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.