yup aber hier müsste man klar definieren was man umsetzen will und zu welchen Kosten.Darii hat geschrieben: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.
Das man das komplette Python mitschleppen muss um alle Fälle abzudecken ist ja logisch, ginge es mit weniger wär ja auch der Interpreter schlanker(!).
Auch braucht man höhere Features wie Speicherverwaltung und Garbage Collection. Das sind jetzt aber primär Speicherkosten.
Die Typisierung schlägt sich aber in Laufzeitkosten nieder, und die 100%ige automatische Vorweg-Bestimmung des statischen Typs ist nicht trivial, da bräuchte man Heuristiken einer erschreckenden KI um ansatzweise zufrieden zu sein.
Heutzutage löst man sowas mit JIT compilern - also während der Laufzeit - JS ist da schon sehr weit, siehe chrome.
Nun zum WAS... also wann will man aber sinnvollerweise ein Script schreiben dass zu C konvertiert wird?
Ich denke da eher an rechenintensive Algorithmen wie z.B. Mandelbrotmengen zu berechnen, wo man vielleicht nur wenige Py-Core-funktionen für Ein und Ausgabe mitzuschleppen.
Der Vorteil wäre hier, dass man nicht in C umdenken muss und in Py seine Algos prototypen und testen könnte.
Generell muss man aber sagen, dass es sinnvoller ist gleich den ganzen Interpreter (Python,Perl,Ruby,...) mitzuschleppen (Speicher ist selten ein problem) und zeitintensive Routinen gleich als C-Extensions zu realisieren. Und dafür ist Cython als Brückensprache gedacht.
