Am Rande notiert ...

Plop: Low-overhead profiling for Python. Das muss ich mir mal genauer angucken, könnte sehr interessant für die Server in der Firma sein, besonders der geringe Profiling-Overhead von nur 2% klingt spannend. Und die Visualisierung ist definitiv eine der besseren bei Profilern für Python.

ErlPort – Erlang port protocol for Python. Ein etwas anderer Ansatz für verteilte Kommunikation ist dieses Modul bei dem einfach die Erlang-Bordmittel für Kommunikation (Ports und Terms) implementiert werden. Damit kann man Systeme bauen die je nach Bedarf Python oder Erlang als Implementierungssprache verwenden.

Hurricane. Klingt interessant, ist ein verteiltes Messaging System das mit verschiedensten Sprachen arbeitet und damit Integration von verschiedenen Systemen biete. Unter anderem dabei is Python mit WSGI und Ruby mit Rails, wodurch z.B. ein verteiltes System auf Basis von Rails und Django denkbar ist. Zusätzlich gibt es noch einen Prozessmanager, mit dem die Prozesse selber nur Standard-IO machen können müssen und dann direkt von Hurricane gemanaged werden. Könnte ich mir gut für das eine oder andere Projekt in der Firma vorstellen.

Jarvis. Da bastelt jemand an sowas wie Light Table für Python (Light Table hat auch Python Support versprochen, aber bisher gibts da nur eine Preview für Clojure). Sieht ganz interessant aus und bringt endlich mal wieder frischen Wind in interaktive Umgebungen für Programmiersprachen.

Make runfcgi fail when database connection is open before fork. Das ist eine Sache nach der ich schon ewige Zeiten jage, zuletzt in ein paar ziemlich wichtigen Projekten. Flup arbeitet so, dass es die WSGI-Anwendung erst initialisiert und mit dieser initialisierten WSGI Anwendung dann die Forks für die Worker macht. Dummerweise gibt es bei uns aber Datenbankzugriffe wärend der Anwendungsinitialisierung – dadurch hat der Basisprozess schon eine offene Datenbankverbindung, jeder Fork kopiert diese Daten. Aber der Socket der Verbindung geht natürlich nicht mit – der neue Prozess denkt nur er wäre verbunden, ist es aber nicht. Zugriffe von denen neuen Prozessen fallen dann mit einer Exception raus. Man kann im verlinkten Patch auch gut den raise auf die Exception einfach durch connection.connection = None ersetzen. Dann wird einfach die Verbindung die sowieso defekt ist weggeworfen und in neuen Prozessen immer eine neue Verbindung aufgebaut. Damit haben wir zumindestens in einem Produktionsumfeld (mit psycopg2) das ganze beheben können und sind guten Mutes, dass es auch bei der Umgebung  mit pyodbc helfen wird.

ronnix/fabtools. Sieht interessant aus – ein paar Tools für Fabric, mit denen man einfache Systempakete und Pythonpakete (auch innerhalb virtual environments) verwalten kann. Sollte ich mir mal angucken, könnte ein paar Sachen etwas vereinfachen bei der Initialisierung von Arbeitsumgebungen. Allerdings benutzt Vagrant im Moment nur Chef und  Puppet und nicht Fabric, wenn ich das richtig erinnere.

#18251 multithreading deadlock in django.models.loading.get_apps – Django. Und noch eine Sache, die uns vielleicht betreffen könnte – Raceconditions zwischen Django-Threads bei der Initialisierung von Django-Applications. Gibt auch schon einen Patch dafür, der das in den Django Internals behebt.

Using SELECT FOR UPDATE in Django. Drin was dran steht. Denn der Django ORM kann derzeit keinen SELECT FOR UPDATE erzeugen, aber manchmal braucht man ihn einfach.

RQ: Simple job queues for Python. Wirklich simpel – man braucht nur einen Redis Server und das Modul und das wars mehr oder weniger. Simple Funktionsaufrufe werden in die Queue geworfen, ausgeführt und Ergebnisse zurückgeliefert. Kein großer Overhead im Code.

TypeQuery. Generische Funktionen für Python. Nur eine einfache Variante mit einem eingeschränkten Zielbereich, aber für manche Sachen durchaus überlegenswert. Derzeit noch single-dispatch auf das erste Argument, aber mulitple dispatch ist geplant. Im Moment also ziemlich identisch in der Funktion zu simplegeneric von PJE. Und sehr ähnlich zu meinem multidispatch, in welchem ich versuche das Modell der Clojure generic methods nachzubauen. Ich muss wohl wirklich mal wieder an multidispatch weiter arbeiten. Oder einfach mehr mit clojure-py spielen, da kann ich dann gleich „the real thing“ benutzen.

Embedding Python in Objective-C: Part 2. Ein interessantes Projekt, dass Python in Objective-C Projekte einbettet und direkte Verbindungen zwischen Python und Objective-C Code erlaubt über automatisch generierte Bridge-Module. Könnte ich mir auch mal bei Gelegenheit angucken, ich hab da immer noch so ein Spielprojekt, das davon profitieren könnte.

jodal/pykka. Eine Actor-Library für Python, baut auf Threads und alternativ auf GEvent auf. Sieht ganz gut aus und könnte für kommunizierende Prozesse recht praktisch sein, wenn das Actor-Modell passt. Eventuell könnte man sowas auch als Basis benutzen um darauf meinen Linda Tuplespace verteilt zu betreiben.

Jython 2.7 alpha1 released!. Wow, das hat zwar ewig gedauert, aber damit sind jetzt die drei größeren alternativen Python Runtimes wenigstens alle auf 2.7 (IronPython, PyPy und jetzt Jython). Wobei ich hoffe, dass Jython 2.7 deutlich an Performance gewonnen hat, denn ansonsten ist es im Vergleich weit abgeschlagen – meine letzten Tests waren eher deprimierend (Faktor 2-3 langsamer als CPython).

cocoa-python – Port of Objective-C runtime to Python using ctypes. Steht eigentlich schon alles im Linktext drin. Interessant, weil der Autor es benutzt um einen Port von Pyglet zu schreiben, der ohne PyOBJC auskommt und damit komplett python-only Sourcecode wäre.

Plumbum: Shell Combinators and More — Plumbum: Shell Combinators. Schaut interessant aus und deutlich durchdachter als manche Alternative die ich mir angeguckt habe (und deutlich ausgebauter als shutil+glob).

PyPy Status Blog: STM update: back to threads?. Die Diskussion und Entwicklung schreitet immer weiter voran – und gerade die Diskussion kommt wieder zurück zum alten Thread-Modell, nur erweitert um eine Funktion zur Definition atomarer Blöcke an Code. Und das ganze so, dass es als Code sogar unter normalen CPython laufen würde (allerdings dann natürlich ohne die Vorteile von STM, denn das gibts da ja nicht, in CPython gibt es weiterhin das GIL) aber trotzdem schon Multicore Architekturen sinnvoll nutzt. Gefällt mir immer besser und ich hoffe, es wird bald im PyPy Main Branch landen.

dirq 1.1.2 documentation. Hey, sowas hab ich vor kurzem gesucht – eine Queue, die auf dem Dateisystem aufbaut. Der Vorteil: einfachste Persistenz und gutes „Debugging“ in dem man einfach im Dateisystem rumprokelt. Der Nachteil ist dann aber oft, dass Queues einige Operationen atomar ausführen müssen – und das kann dann schon etwas hakeliger werden, wenn man es richtig hinbekommen will. Dieses hier ist die Portierung eines schon länger existierenden Perl-Moduls, die Chancen, dass die meisten Kinderkrankheiten raus sind, sind also recht hoch. Das API jedenfalls sieht nett simpel aus. Definitiv mal genauer angucken.

pycounters. Muss ich mir mal angucken, damit kann man recht einfach Counter in ein Projekt integrieren, die Daten über z.B. Funktionsaufrufe oder ähnliches liefern – im Prinzip sowas wie die Windows Performancecounter, nur eben für Python-Projekte.

virtualenv-clone 0.2.2 : Python Package Index. Noch nicht ausprobiert, aber nach Beschreibung kopiert es virtualenv Environments und repariert Import-Pfade, Egg-Files und .pth Inhalte sowie Scripte. Und soll vollständiger arbeiten als die relocatable virtualenvs.

uWSGI. Hatte ich scheinbar noch nicht – ein Kollege hat mich gerade darauf hingewiesen. Könnte besonders für Django-Projekte interessant sein, weil es wesentlich flexiblere Prozesssteuerung und Monitoring bietet als der flup-basierte runfcgi in Django.

RQ: Documentation. Hmm, python-job-queue auf Redis-Basis mit einem recht simplen Interface. Könnte eine interessante Alternative zu Celery sein.

haypo/pysandbox. Mal wieder was zum Angucken: eine Sandkiste für Pythonscripte. Laut Projektbeschreibung nicht unbedingt eine Sicherheitslösung sondern eher nur ein einfacher Schutz für den Python Prozess. Somit wäre es zumindestens als einfache Absicherung eines Hauptprozesses gegen Fehler in Erweiterungsscripten nutzbar.

pyp – Python Power at the Prompt – Google Project Hosting. Da ich lieber mit Python als mit awk oder perl rumspiele, ist das hier ein recht interessantes Tool. Man kann damit Textfiles mit ähnlichen Features bearbeiten wie mit awk und perl. Und auch das ganze als Einzeiler – pyp definiert dafür einfach ein paar Variablen und Operatoren, die man verwenden kann. Sieht ganz gut aus.

Clojure-Py. Noch kann ich nicht so genau sagen was ich davon halte, aber jemand baut Clojure (die Sprache) mit Python und PyPy als Zielplattform. Grundsätzlich sicherlich eine interessante Idee, denn die LLVM-basierte JIT Implementierung von PyPy kann ja auch durchaus andere Sachen kompilieren. Und da ich sowohl ein Python als auch ein Lisa Fan bin, muss sowas ja meine Neugierde wecken. Der Sprachumfang von Clojure ist noch nicht komplett abgebildet, aber das kann ja noch kommen.

Create a package for IOS — Kivy 1.1.2-dev documentation. Kivy – ein GUI Framework für Python – bietet jetzt auch einen Weg die Anwendung für iOS zu packen und zum Beispiel auf einem iPad laufen zu lassen. Keine Ahnung ob das dann auch wirklich im AppStore aktzeptiert wird, die Programmierer haben aber schon  ein Programm auf der Basis rein bekommen, die Chancen stehen also gut.

JulianEberius/SublimeRope. Sehr interessant – eine Integration von Python Rope (eine Refactoring-Library für Python Code, die in Python geschrieben ist) in Sublime Text 2. Damit wird gibt es dann Refactorings direkt in ST2 – eines der Features, die ich in PyCharm lieben gelernt habe (speziell syntaktisch korrektes Rename und extract method) und die in ST2 bisher fehlten. Sollte ich mir vielleicht mal angucken, wobei ich bei Projekten in denen ich Refactoring brauche dann doch eher gleich zu PyCharm  greife, einfach weil noch viele andere Sachen dazu kommen (z.B. der integrierte Debugger). Irgendwo tendiere ich in letzter Zeit doch eher dazu zwischen Editoren für einfache Dinge und IDEs für große Projekte zu wechseln, auch wenn man dann verschiedene Bedienungen lernen muss – die Einsatzzwecke sind einfach zu verschieden um das mit nur einem Tool zu erledigen.

PySide for Android thp.io. Das klingt doch schon mal sehr interessant – damit hätte ich dann eine mir deutlich genehmere Programmiersprache zur Verfügung, um Android-Programme zu bauen. Wobei die Startzeit von in Python geschriebenen Activities warscheinlich alleine schon auf Grund der Ladezeiten des Python-Stacks und der Qt Libraries ein bischen heftiger sein könnten. Aber um mal einfach ein paar kleine Tools zum Eigengebrauch zu bauen sollte das egal sein.

pyprocessing – A Processing-like environment for doing graphics with Python – Google Project Hosting. Processing, für Python. Steht abet ja schon I’m Titel.

stochastic-technologies/goatfish – GitHub. Schaut interessant aus, ein kleines Python-Modul welches SQLite als Persistenzlayer für beliebige Objekte benutzt. Nicht auf dem Level eines ORM, sondern eher auf dem Level eines komplexeren Key-Value-Stores. Ganz interessant für die üblichen kleinen Hacks bei denen man mal schnell Objekt-Persistenz braucht, aber aufgrund der simplen Strukturen eigentlich keinen Sinn in einer ausgebauten Datenmodellierung sieht – oder wenn man während des Prototypings noch gar nicht weiss, wie die Strukturen aussehen werden.

Camelot – See it. Auf jeden Fall mal angucken: das ist ein Python Paket mit dem aus Modellbeschreibungen mit SQLAlchemy automatisch QT GUIs produziert werden. Inspiriert vom Django Administrator liefert es einen schnellen Einstieg in Modell-orientierte Programme, und könnte daher im Bereich von einfachen DB Anwendungen durchaus als eine Art 4GL benutzt werden – und da Python drunter steckt, gibt es all die weiteren Möglichkeiten von Python gleich dazu. Und wenn man das mit SQLite kombiniert, könnte sowas auch recht nett für die üblichen kleinen Desktop-Tools sein, die man so im Laufe seines Lebens zusammendengelt.