Spekulationen über die Zukunft von Processing.py

Vor etwa zwei Wochen wurde auf den Diskussionsseiten der Processing Foundation eine interessante Diskussion angestoßen: »Was sind die aktuellen Pläne für die Zukunft des Processing-Python-Modus oder alternativ für ein Python-Paket, das auf den Kernideen von Processing basiert, wie zum Beispiel p5py/p5 oder py5, das aber genauso einfach zu installieren ist wie der Python-Modus?«

Leider versandete die Diskussion zu einem großen Teil in einer Gegenüberstellung von Python 2.7 und Python 3 oder – ganz überflüssig – in einem Vergleich zwischen camelCase (Standard in Java und damit auch in Processing.py) und snake_case (Standard in (C)Python). Um das für alle noch einmal klarzustellen: Die Bemühungen um einen (C)Python-Processing-Mode haben – zumindest aus meiner Sicht – nichts mit Python 2.7 versus Python 3 zu tun, sondern mit dem Wunsch, Bibliotheken wie NumPy, SciPy oder Pandas zusammen mit Processing einzusetzen. Processing (und damit auch Processing.py) basiert auf Java und damit laufen damit naturgemäß die in C (oder gar in FORTRAN) implementierten Moudule nicht, sie benötigen zwingend ein (C)Python¹.

Und das ist die Hoffnung, die ich speziell auf py5 setze, da dieses Modul mithilfe von JPype die .jar-Dateien von Processing.py in (C)Python zugänglich macht. Wenn nur die Probleme mit der macOS-Version nicht wären. Zwar hat Tristan Bunn eine Modifikation von Thonny bereitgestellt, die py5 auch auf dem Mac lauffähig macht, aber während es – siehe Screenshot oben – auf Processing 4 engepaßte Updates für andere Betriebssysteme gibt, verharrt mein macOS-Thonny weiterhin im freundlichen Schwarz. Doch noch habe ich die Hoffnung auf ein Update nicht aufgegeben und warte weiter ab.

Und was die Diskussion über camelCase und snake_case angeht – meine Güte, das sind Konventionen, niemand hindert Euch daran, Eure Variablen so zu schreiben, wie Euch der Schnabel gewachsen ist. Zwar nutze auch ich meistens in (C)Python den snake_case, aber richtig glücklich bin ich damit nicht, weil er meine Markdown-Texte verwirrt und Markdown daher gelegentlich glaubt, diese Variablen kursiv schreiben zu müssen.

Aber es gab in dem Thread auch einiges interessantes zu entdcken: Einmal der Hinweis auf Graal Python, eine polyglotte (unter anderem JavaScript, Python, Ruby) freie und schnelle JVM, die auch mit NumPy, SciPy und anderen (C)Python-Modulen zusammenarbeiten will (Python >= 3.8.5).

Und dann gibt es auch noch pyp5js, ein Interpreter, der Python-Quellcode nach P5.js, also nach JavaScript übersetzt. Er steht unter der LGPL-3.0 und den Quellcode gibt es auf GitHub.

Allen Widrigkeiten zum Trotz sieht es also gar nicht so schlecht aus in der Python-Processing-Welt. Still digging!

1 (Email-) Kommentar

Danke für den Beitrag, die Diskussion über die Zukunft von Python in Processing 4 hätt’ ich sicher nicht mitbekommen.
Habe gerade Processing 4 beta 6 installiert, nur um zu entdecken, dass da im Python mode gar nichts geht: https://github.com/processing/processing4/issues/409; also zurück zu beta 5. Jetzt funktionieren die meisten Programme wieder, nur "alte" Bibliotheken wie Video lassen sich nicht verwenden … also doch wieder 3.5.4?
Auf meiner Festplatte gibt’s mittlerweile die Verzeichnisse p3py, p4java und p4py, das macht das ganze nicht übersichtlicher :-(

– Roland R. (Kommentieren) (#)

(Kommentieren)