Worknote: PyProcessing und Anaconda-Python

Auch wenn die Arbeit mit Processing.py, der Python-Version von Processing sehr viel Spaß macht, gelangt man doch manchmal an die Grenze, und zwar immer dann, wenn man für ein Problem gerne die Vorzüge von numpy, SciPy oder pandas nutzen möchte. Da Processing.py ja bekanntlich auf Jython – also der Java-Version von Python – aufsetzt, die genannten Module aber zwingend ein CPython verlangen, werden sie also nie mit Processing.py verheiratet werden können.

Es gibt aber auch noch so etwas wie eine reine Python-Implementierung von Processing, nämlich PyProcessing, die auf PyGlet aufsetzt. Und da es mir ja schon gelungen war, PyGlet mit einem Anaconda-Python zu verheiraten, habe ich versucht, darauf PyProcessing aufzusetzten. Die Installation war einfach. Nach dem Download einfach das Archiv entpacken und dann im Terminal in das Verzeichnis des entpackten Archivs wechseln. Ich hatte auf dem Schreibtisch entpackt, also

cd /Users/admin/Desktop/PyProcessing

brachte mich dahin, wo ich hinwollte und

sudo python setup.py install

erledigte dann die ganze Installationsarbeit für mich (wer PyGlet noch nicht installiert hat, muß das vorher installieren, hier steht, wie das geht).

Ob die Installation gelungen war, habe ich dann mit diesem kleinen Script überprüft:

# -*- coding: utf-8 -*-

from PyProcessing import *

def setup():
    size(400, 400)
    stroke(255)

def draw():
    background(192, 64, 0)
    line(150, 25, mouse.x, mouse.y)

run()

Der obige Screenshot zeigt das Ergebnis. Im Script sieht man aber auch, daß PyProcessing (notwendigerweise) keine Eins-zu-Eins-Umsetzung von Processing ist. So heißen zum Beispiel die Processing-Variablen mouseX und mouseY in PyProcessing mouse.x und mouse.y. Außerdem muß zum Schluß eines Sketches immer die Funktion run() aufgerufen werden, sonst geht gar nichts. Ein genauerer Blick in die Dokumentation ist daher dringend zu empfehlen.

Caveat

Eines muß ich jedoch noch mitteilen. Während die Zusammenarbeit von PyProcessing und dem Anaconda-Python – wie auch obiger Screenshot zeigt – anstandslos funktionierte, gab es seltsamerweise Probleme mit der Python-IDE Rodeo: Während die »alte« Version 1.3 problemlos mit PyProcessing zusammenarbeitete, gab es nach einem Update auf die aktuelle Version 2.0 unverständliche Fehlermeldungen, die seltsamerweise alle PyGlet betrafen. Ein kurzer Test mit Pyglet only-Skript zeigte aber, daß dieses ohne Fehlermeldung auch mit Rodeo 2.0 lief. Ich weiß daher noch nicht, was die Ursache für diese Fehler ist. Still digging!

Und natürlich muß sich jeder selber überlegen, ob er einem Modul vertraut, das offensichtlich seit 2012 kein Update mehr erfahren hat. Aber das trifft auch auf die Alternative Nodebox for OpenGL und im gewissen Sinne auch auf PyGame zu. Ich werde daher weiterhin eher auf Processing.py setzen. Aber manchmal gibt es eben Situationen, in denen man das Anaconda-Python wirklich braucht.

Links und mehr

Zum Abschluß noch ein paar Links zu Processing.py und PyProcessing, die mir die letzten Tage untergekommen sind:

• Eine ganz große Fundgrupe zu Processing.py ist das Blog Second Coming For Processing.py, das zwar wenige, aber sehr lehrreiche Beiträge enthält.

• Auf XOR gibt es eine kurze Einführung in Processing.py.

• Auf diesen Slides wird Werbung für Data Visualizations with Pyprocessing gemacht.

Und last but not least gibt es auch noch dieses Video Introduction to Graphics with PyProcessing.

---

(Kommentieren)