CRE088 Python und PyPy

Veröffentlicht am von

Der analytische Interpreter-Generator PyPy setzt auf Python als Universalsprache

Episode image forCRE088 Python und PyPy

In dieser Ausgabe von Chaosradio Express geht es in die technischen Details eines speziellen Projektes in der Welt der Programmiersprachen und Compiler: PyPy. Im Gespräch mit Tim Pritlove erörtert Holger Krekel Hintergründe zur Programmierung in Python und die Motivation zum Start des PyPy-Projektes.

Zunächst widmet sich die Sendung der Programmiersprache Python selbst und erläutert verschiedene Konzepte und Konventionen der Programmierung. Hier kommen unter anderem zur Sprache: direkte Evaluation, die spezielle Syntax von Python unter Verwendung von Einrückung anstatt von Trennzeichen, der Einsatz von Regressionstest in der Programmierung, Kooperatives Programmierung in einem Projekt mit Sprints und Modulen, Namespaces, die verfügbaren Python-Interpreter und -Laufzeitumgebungen, Einsatzmöglichkeiten und Stärken von Python, populäre Bibliotheken, Projekte und Organisationen, die Python verwenden.

Im zweiten Teil konzentriert sich das Gespräch auf PyPy. Hier werden erläutert: wie es zu dem Projekt kam und welche Ziele es verfolgt, wie man einem Programm dadurch analysiert, in dem man ihm zur Laufzeit dabei zuschaut, wie es ausgeführt wird, wie man daraus einen Übersetzter in beliebige Zielplattformen generiert, die automatische Erzeugung von Just-In-Compilern, die Low Level Virtual Machine (LLVM), EU-Förderung für das PyPy-Projekt und mögliche Anwendungen für PyPy in der Zukunft.

avatar
Tim Pritlove
Twitter Icon @timpritlove@mastodon.social Icon Website Icon Spenden via PayPal Icon
avatar
Holger Krekel
Twitter Icon Website Icon
Shownotes

Links:

44 Gedanken zu „CRE088 Python und PyPy“

  3. jopp, war ne klasse sendung, war auch nich sooo schwer zu folgen ;)
    und echt ein interessantes projekt!
    ich wollt mich ja schon länger mal in phyton einarbeiten, um mich evtl auf längere sicht dort niederzulassen – mit pypy muss ich mir dann wohl auch weniger sorgen machen, dass phyton eine randerscheinung bleibt/wird!
    sehr sehr nice!
    gerade wohl auch, für mich im forschungsbereich, wo ja doch viel semiprofessionell programmiert werden muss, aber aufgrund der komplexen berechnungen und aber begrenzten rechenkapazität, trotzdem sehr viel auf performance geachtet werden muss!
    muss ich mal ausprobieren, inwiefern pypy mir dann vielleicht bei dieser problemstellung unter die arme greifen kann…

    Antworten ↓

  4. Ich programmier mir zwar in Python meine eigenen kleinen Skripts, aber ich verwende Tabs. Tabs sind viel praktischer weil sie atomar sind. Ein Tab einrücken, ein Backspace wieder zurück. Ich versteh nicht wozu Spaces zur Einrückung gut sein sollen. Kann mir das mal jemand erklären? Eben auch aus den Gründen die Tim erwähnt hat.

    Antworten ↓

    • Spaces statt Tabs macht man, da man das besser aus Webseiten C & Pn kann.
      Tabulatoren lassen sich nicht wirklich in HTML darstellen.

      Antworten ↓

  5. Tim – du bist echt ein Fiesling – erst (viel zu) „lange“ nichts machen, dann ankündigen, dass erstmal Pause ist und dann eine so unverschämt interesstante Folge zum Abschied in die Sommerpause hinlegen – das ist einfach abgrundtief grausam ;).

    Antworten ↓

  6. Na also das war ja mal wieder ein Hammer, sogar ich als Halb-Laie mit beschränkten Python oder Codekenntnissen generell hab am Ende verstanden worum es ging. Es waren ein bisschen viele halb eingedeutschte Anglizismen dabei aber so ist das halt wenn man sich über sowas unterhält schätze ich. Wieder mal eine tolle Folge und ich würde jemandem der keine Ahnung hat PyPy als „Echtzeit Reverse Engineering“ erklären vorausgesetzt der/diejenige weiss wenigstens was Reverse Engineering ist. Aber im CCC Umfeld müsste das ja ein leicht zu erfüllendes Kriterium sein.

    Antworten ↓

  7. Pingback: System » Blog Archi » Chaosradio Express 088 - Python und PyPy

  10. Hi,

    schönder Podcast, danke!
    Über pythen wür dich mir noch mehr wünschen!
    Eine, aber wirklich nur eine Sache, ist mir diesmal negativ aufgefallen:
    Ab Minute 45 seid ihr euch für ein paar Minuten lang ständig ins Wort gefallen und gehetz gesprochen, so als ob man noch schnell etwas sagen müsste, bevor das Mirko wieder weg ist :-). Das war kurzzeitig anstrengend.

    Antworten ↓

  12. Neue Programmiersprachen sind natürlich immer toll und Verbesserungen wie PyPy.
    Ich hoffe Microsoft schafft es nicht in irgend einer Art und Weise das zu monopolisieren.
    Also schön für alle Betriebsysteme Standards für PyPy schaffen und gut für Neulinge dokumentieren, damit alle was davon haben.
    PyPy darf kein neues Visual Basic werden.

    Antworten ↓

  13. zur frage ob die leute es beim ersten mal hören verstanden haben:

    „Nein!“ <- is zumindest bei mir so…
    Trozdem ein interessanter podcast, werd ihn mir wohl nochmal anhören wenn ich grad nix zu tun hab…

    P.S.: mach doch mal was zu Virtualisierung/XEN.

    Antworten ↓

  14. Klasse Podcast, wie eigentlich immer.

    Schwer, aber nicht unmöglich, zu verstehen.

    Die Pause kommt höchst ungelegen, da ich gerade damit fertig bin die ganzen „alten“ Folgen aufzuholen.

    Viel Spaß und Erfolg bei den „weltlichen“ Dingen, und dann hoffentlich weiter so. :-)

    Antworten ↓

  16. Wie immer ein äussert hörenswerter Podcast. Ich bin nicht unbedingt ein Python fanboy, grad wegen der Einrückungsgeschichte. Die geht mir etwas gehen den Strich. Aber wenn schon Einrückung, dann mit Tab. Wobei man halt die Styling Guides von Python den Vorrang geben müsste. Jedenfalls ist PyPy ein sehr interessantes Projekt und ne gute Horizonterweiterung :)

    Antworten ↓

  17. Klasse Podcast – ist einer der besten, wie ich finde.

    Zu der „Einrueckproblematik“ bleibt eigendlich nur zu sagen, dass aktuelle Editoren eine Funktion zum ersetzen von durch Spaces bieten, die groesstenteils auch defaultmaessig aktiviert ist.

    Wer Gruende sucht, sich nicht mit neuen Programmiersprachen zu beschaeftigen wird wohl immer etwas finden… ;-)

    Antworten ↓

  18. Die Folge war ziemlich interessant.
    Relativ unnützes Spezialwissen weil PyPy einfach zu speziell ist. Aber gerade sowas wollen wir doch ;-) Mehr davon!

    Um Flagge zu zeigen: Ich liebe Python.

    Antworten ↓

  19. So, nachdem ich fleissig, regelmäßig und begeistert CRE höre, wollte ich diesen überdurchschnittlich interessanten cast doch mal zum anlass nehmen und sag: klasse!

    Ich war erst etwas enttäuscht, dass du dich auf ein eher peripheres thema bei Python gestürzt hast, aber dann doch sehr angetan.

    LLVM wär in der tat auch sehr spannend.

    Antworten ↓

  20. Pingback: Chaosradio Express 088: Python und pypy « kopfueber

  21. Wirds denn auch mal ne Sendung zu Java geben, evt auch mit irgend nem Spezialbezug ? Bei Py war die Kombi mit nem speziellen Thema wie PyPy ja sehr fruchtbar :-)

    Antworten ↓

  22. Bin über den pypy-Blog auf den Chaosradio podcast gestoßen. Respekt! Super Interview. Hat Lust gemacht auf mehr…

    Nur: Ein echter Smalltalker schreibt seinen Interpreter natürlich (wie bei Squeak geschehen) in Smalltalk :) Ob der JIT von PyPy dann wirklich mehr Performance gibt, wird die Zukunft zeigen.

    Antworten ↓

  24. Juhu – ich hab durchgehalten!!!
    … und das, obwohl ich nur in den Grundzügen Programmieren kann.

    Allerdings habe ich noch nicht so ganz verstanden, weshalb man mit PyPy nur Interpreter übersetzen sollte. Ich könnte doch auch ein Python-Programm schreiben und dann aus Performance-Gründen als C ausführen.
    Oder war dieser Punkt das, was im Ausblick auf die Zukunft angesprochen wurde?

    Antworten ↓

  26. F30: Grundsätzlich lassen sich RPython programme z.leistungsfähige Interpreter B. nach C übersetzen, ja. Aber das ist derzeit nicht das hauptanliegen der PyPy entwickler, die leistungsfähige Interpreter mit JIT-Compiler produzieren wollen. Das bedeutet, dass du beim Versuch, „Applikationen“ in RPython zu programmieren nur auf wenig Unterstützung zählen könntest. Könnte sein, dass wenn sich zahlende kunden finden, das anders aussähe :)

    In unseren FAQ wird das auch noch mal erläutert:

    http://codespeak.net/pypy/dist/pypy/doc/faq.html#can-i-use-pypy-and-rpython-to-compile-smaller-parts-of-my-python-program

    gruss, holger

    Antworten ↓

  27. Hallo,
    in einem der letzten der Chaosradios habt ihr irgendeine Sendung die sich mit ähnlichen Themen wie CR beschäftigt auf Fritz genannt.
    Hab den Namen leider nicht wiedergefunden, kann mir einer auf die Sprünge helfen?
    Danke und weiter so :)

    Antworten ↓

  31. Also ich kann sagen dass ich sowas von überhaupt keine Ahnung von programmieren hab wie sonst nur selten wer ;-) Ab und zu hab ich zwar Bahnhof verstanden, aber ich konnte der Sendung im großen und ganzen gut folgen. …denke ich :-)
    Lg
    Rainer

    Antworten ↓

  37. Hi,

    verstehe ich das richtig: Wenn man ein Programm mit PyPy in z.B. C übersetzen möchte, muss man es 100% Unit-testen? Weil sonst würden ja beim „Interpreter zuschauen“ nur die Teile des Programms übersetzt, die durchlaufen werden…

    Gruß

    Daniel

    Antworten ↓

  38. Hallo Daniel, ein rpython programm braucht keine unit-tests um durch pypy übersetzt zu werden. Es braucht nur ein funktionsobjekt als entry-point. allerdings sind automatisierte tests sehr hilfreich, nicht zuletzt, weil der übersetzungsprozess nicht unbedingt hilfreiche Fehlermeldungen gibt. g. holger

    Antworten ↓

  39. Hallo Holger,

    was ich mich während der Sendung gefragt habe ist, ob ihr wohl PyPy auch mal selber mit PyPy „übersetzen“ lassen habt um dadurch evtl. Geschwindigkeitsvorteile zu erzielen?

    Viele Grüße,

    Christoph

    Antworten ↓

  40. hi christoph,

    ja, unser Python Interpreter kann sich selbst übersetzen. Das bringt aber keine wesentlichen Vorteile. Vom „Übersetzenden“ Python ist beim Resultat eigentlich nichts mehr zu sehen, da ist es also ziemlich egal, ob man ein generiertes „pypy-c“ oder ein „cpython“ nimmt. Was wir als ein gutes zeichen ansehen, denn es soll ja möglichst kompatibel sein :)

    holger

    Antworten ↓

  41. Hi Holger,

    da habe ich mich wohl falsch ausgedrückt. Ich meinte eher den „Translator“, der ja (wenn ich mich recht erinnere) auch in Python geschrieben ist. Ist es genau so schnell, den Translator in cpython ablaufen zu lassen, wie ihn z. b. durch pypy nach c generieren zu lassen und dann als native c-Applikation zu verwenden? Oder muss der Translator auch in Python sein, damit er den zu übersetzenden Interpreter besser beobachten kann? (Jetzt verknoten sich bei mir gerade wieder die Gehirnwindungen :-))

    Christoph

    Antworten ↓

  42. Im Translator benutzten wir volles Python ohne Einschränkungen. Daher kann dieser selbst nicht in nativen Code übersetzt werden. Unser Python Interpreter ist in eingeschränktem Python (RPython) geschrieben und kann daher übersetzt werden – was das haupsächliche ziel der ganzen Übung ist. grüßle, holger

    Antworten ↓

  43. Pingback: CRE122 Compilerbau und Typtheorie | CRE: Technik, Kultur, Gesellschaft

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.