python - 20.1.2006 - 3.7.2007
httplib2.py - bessere HTTP library als die in der Standardbibliothek.
PyCells - berechnende Speicherzellen. Im Prinzip sowas wie eine Maschinerie für Tabellenkalkulationen. Hatte ich das nicht schon mal? Egal. Ist trotzdem interessant.
Beautiful Soup: We called him Tortoise because he taught us. - auch das nicht neu, aber praktisch: ein HTML-Parser für kaputtes HTML. In Python. (und ja, ich muss gerade HTML-browsing automatisieren für Tests)
twill: a simple scripting language for Web browsing - automatisiertes web-browsen. Hatte ich wohl schon mal, aber egal, wird sonst auch ständig was wiederholt.
PyInstaller - interessante Alternative zu py2exe, die sowohl unter Windows als auch unter Linux ausführbare Dateien erstellen kann.
Kamelia - interessantes Konzept: Komponentenprogrammierung in Python. Komponenten werden über threads parallel betrieben und kommunizieren über ein einfaches Pipe-Interface. Ähnlich der Unix Shell, nur für Highl-Level Objekte und innerhalb einer Programmiersprache.
DjangoKit - klasse Idee. Im Prinzip Apollo mit Python - Django-Anwendungen können einfach in echte OSX-Anwendungen gewandelt werden. Könnte durchaus interessant werden.
appscript - Python als Alternative zu AppleScript (hatte ich den nicht schon mal?)
Python, Django and DB2: we need your input! - klingt als ob es bald ein DBAPI2 modul für Python und DB/2 direkt von der Quelle geben wird.
soaplib - ab und an gibts doch mal was neues. Neben dem doch recht langsam daherdümpelnden SOAPpy und den meiner Meinung nach etwas overengeneered ZSI, gibts jetzt mit soaplib noch eine weitere Python-Bibliothek für SOAP Webservices. Mal angucken.
boto - eine Library zum Zugriff auf Amazon Webservices. Unterstützt werden S3, SQS und EC2 - genau das, was ich brauche. Dokumentation sieht auch ganz brauchbar aus.
Jython 2.2 Beta - endlich mal wieder was neues von Jython, der Python-Implementation für die Java VM. Immer noch Python 2.2 Syntax Stand, aber immerhin ein neuer Release. Allerdings liest sich die Roadmap etwas krass, wenn da von der Code-Qualität gesprochen wird ...
ModWsgi - ein Apache-Modul für WSGI-Applikationen (WSGI ist ein python-Standard für Webanwendungen).
IronPython und libsecondlife
libsecondlife ist ja eine C#-Reimplementation des SecondLife Protokolls. IronPython ist ein Python auf .NET. Sollte man zusammen benutzen können. Geht auch. Allerdings ist IronPython eben nicht Python - die ganze Standardbibliothek fehlt grösstenteils (auch wenn eine Menge der pure-Python-Module sicherlich funktionieren würden). Und externe Libraries werden auch anders gehandhabt. Folgendes macht glücklich:
import clr
clr.AddReferenceToFile("libsecondlife.dll")
import libsecondlife
Damit hab ich das ganze zusammengeladen bekommen. Vielleicht ein Start für mich damit mal rumzuspielen.
Python for Maemo - auf dem Nokia Tablett mit Python 2.5 spielen.
[Google Pagerank Algorithm](http://kraeutler.net/vincent/essays/google page rank in python) - in Python. Interessant.
ajp-wsgi - eine auf AJP (das Java Server Protokol) aufbauende Implementierung von WSGI (dem abstrakten Python Server Protokol), die komplett in C geschrieben ist und die Python-Anwendungen über eingebettete Python-Interpreter ausführt. Könnte sehr interessant für effizienten Betrieb von Python-Anwendungen sein.
The Django Book - progressive Beta-Releases der Django-Buch-Kapitel im Web (mit Angaben wann die Kapitel online gehen).
Sicherheitslücke in Python 2.3 und aufwärts - definitiv nicht nur Ubuntu, sondern auch Debian. Ubuntu nur deshalb verlinkt, weil bei Debian noch kein Security-Advisory ist. Schläft da jemand?
Introducing Django 0.95 - neue Django-Release raus. Magic removed.
WPHP - PHP über einen FastCGI-Server aus Python heraus aufrufen. Damit könnte PHP z.B. in Django integriert werden.
TLS Lite - nette kleine Python-only Lib für SSL, TLS und low-level X509 Handling. Recht brauchbar für Quick-Off Projekte und für grössere Systeme integriert es mit andren PKI-Libraries für Python.
CLPython - an implementation of Python in Common Lisp - ok, das ist schon abgedreht.
Python Cheese Shop : saprfc 0.08 - noch ein weiteres SAP-RFC Modul für Python.
Generische Tabellenrelationen für Django. Sehr interessant, das macht Sachen wie Tags in Datenmodellen wesentlich einfacher. Ich müsste damit einiges aus meiner Stuff-Library loswerden können.
Automatic Pickle Serialization and Deserialization with PostgreSQL - sehr interessant, automatisches pickle/unpickle bei Nutzung von PsycoPG2.
Feedjack - A Django+Python Powered Feed Aggregator (Planet) - könnte vielleicht als Ersatz für das doch recht angestaubte WordPress bei metaowl.de eingesetzt werden?
PyCells and peak.events - Phillip J. Eby über Cells und was sie für event-orientiertes Programmieren bedeuten. Besonders interessant, da ja beim Google Summer of Code eines der Projekte eine Python-Implementierung des Cell-Konzeptes ist.
Django for non-programmers - Django aus der Sicht eines Webdesigners.
Django Weblog "magic-removal" branch merged - gaaaah. Arbeit. Mist.
Python 3000 - Adaptation or Generic Functions?
Python 3000 - Adaptation or Generic Functions? Wow. GvR sieht das Licht! Generische Funktionen in Python 3000! Hell freezes over, third time ...
python-constraint - hatte ich den schon? Egal, es gibt einen neuen Link und im Fernsehen wird eh auch alles wiederholt. Constraint-Solver in Python. Kann durchaus mal interessant für Projekte werden.
Merquery, Text Indexing and Search with a Focus - eine Volltextsuchmaschine in Python speziell für RAD-Frameworks? Mal gucken was da rauskommt.
MP3 Python Module - einfache Lib zum Zugriff auf MP3 Informationen.
Divmod - eine ganze Reihe von sehr interessanten Python Projekten. Natürlich auch eigenes Webframework und eigener ORM, aber auch ein paar kleinere, interessante Sachen wie z.B. ein Bayesian Classifier.
Tail Call Optimization in Python
Anfang des Monats hab ich mich noch darüber geärgert, das GvR keine Tail-Call Optimierung in Python will - weil er meint, das wäre ein Feature das kein einfaches Interface haben kann. Auf [Lambda the Ultimate] gibts dazu auch einen Kommentar - denn logischerweise hat dieses Statement von GvR zu einiger Erheiterung in der Lisp-Community geführt. Ganz besonders putzig daran: es gibt eine Lösung Tail-Calls per Dekorator optimieren zu lassen - in dem Python einfach im Stack rumfummelt (dank Stack-Introspection geht das ganz gut). Soviel zum Thema Rube Goldberg Device - der Dekorator ist extrem kompakt, da ist wirklich nicht viel Komplexität enthalten. Natürlich ist die Optimierung nicht wirklich optimal - sie vermeidet zwar den Stacküberlauf, aber benutzt Exception-Handling um die Funktionsaufrufe zu vermeiden, was dann doch etwas auf die Performance schlägt. Aber für die einfache Übertragung rekursiver Algorithmen kann das trotzdem durchaus nützlich sein.
Und warum wird sowas jetzt nicht als bessere, effizientere Lösung direkt in Python eingebaut? Python 2.5 kriegt von Perl geerbte bedingte Ausdrücke ( value if condition else othervalue ), aber sowas wie ein einfacher Dekorator zur Optimierung von bestimmten Funktionsaufrufen nicht?
pyOpenSSL - Python interface to the OpenSSL library - relativ vollständige Bindings. Sieht deutlich besser aus als die bisherigen Libs die ich mir angeguckt habe.
Language Design Is Not Just Solving Puzzles
Language Design Is Not Just Solving Puzzles ist ein recht interessanter Artikel von Guido van Rossum über die Unmöglichkeit einer eleganten Syntax für mehrzeilige Lambdas in Python. Lesenswert und in weiten Teilen stimme ich ihm zu. Allerdings stolpere ich dann über so einen letzten Absatz:
And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable. This is also the reason why Python will never have continuations, and even why I'm uninterested in optimizing tail recursion. But that's for another installment.
Ich bin durchaus bereit zu akzeptieren das Continuations komplex sind - aber nicht wegen des Interfaces. Denn im Interface für Continuations braucht man nur den callcc Aufruf zum Binden der Continuation und eine einfache Funktionssyntax zum Auslösen der Continuation. Das Hauptproblem bei Continuations liegt in der Kooperation mit Generatoren und Exceptions - was passiert, wenn eine Continuation innerhalb eines Generators ausgelöst wird? Was passiert, wenn innerhalb einer Continuation eine Exception ausgelöst wird? Das sind die schwierigen Aspekte - die übrigens auch Scheme-Implementatoren zum Schwitzen bringen, weshalb bei denen in der Regel Exceptions nicht so gerne gesehen werden (gleiches Problem, einfach nur aus der anderen Richtung betrachtet).
Also ok, keine Continuations in Python - auch wenn wir schon längst poor-mans-continuations mit pickable generators bekommen (oder mit Greenlets, oder mit cloneable Coroutines, oder einer der anderen vielen Ansätze um Subsets von Continuation-Features zu erhalten).
Aber was bitte schön ist komplex an Tail-Call-Optimization (denn es geht nicht nur um Tail-Recursion)? Die ist so primitiv, das sie transparent für den Programmierer implementiert werden kann - wenn ein Tailcall vorliegt, keine Rücksprungadresse auf dem Stack notieren, sondern die Parameter im Stackframe umladen und einen einfachen Jump notieren. Wenn man nett sein will, kann man noch eine Pseudofunktion "tailcall" einführen, welche eine Exception auslöst wenn sie nicht in einer Tailcall-Position ausgeführt werden soll. Es mag weitere Bedingungen geben, unter denen Tailcalls nicht optimiert werden können - aber diese können genauso in eine entsprechende Prüfung einfließen.
Gerade der Funktions-Overhead ist es ja, der manche Algorithmen in Scriptsprachen nur unschön implementierbar macht. Und Tail-Call-Optimization würde da definitiv helfen. Ganz besonders in Situationen, in denen man eine Kette von kleinen Funktionsaufrufen hat. Wegen meiner kann es auch gerne eine Optimierung sein, die nur bei -O (oder einem -O2 oder sonstwas) aktiviert wird.
Django-Vorlagen sind nicht begrenzt
shannon -jj behrens hält die Django-Vorlagensprache für begrenzt - weil sie keine Funktionen mit Parametern hat, um HTML-Snippets wiederzuverwenden. Natürlich ist die offizielle - und vereinfachte - Antwort darauf, dass die Django-Vorlagensprache absichtlich so einfach ist, damit sie leicht von Nicht-Programmierern gelernt werden kann (da Designer nicht unbedingt Programmierer sind). Das ist eine ziemlich gute Begründung, aber ich denke, das ist ein bisschen zu vereinfacht.
Hier ist die längere - vollständigere - Antwort auf diesen Vorwurf: Die Django-Vorlagensprache ist überhaupt nicht begrenzt. Ja, ich weiß, dass die "include" und "block" Tags nicht parametrisierbar sind und daher nicht oft für komplexere Situationen nützlich sind (zumindest, wenn Sie nicht in der Namensraum-Hölle enden wollen, weil Sie einige Template-Globals im Kontext weitergeben).
Was sollten Sie also tun, wenn Sie feststellen, dass Ihre Vorlagen komplexeren Code benötigen? Eine Möglichkeit wäre, die Daten in der View-Funktion vorzuberechnen und sie über den Kontext an die Vorlage weiterzugeben - auf diese Weise hat die Vorlage die fertigen Daten und kann sie direkt präsentieren.
Aber was tun, wenn Sie nicht vorberechnen können, weil Sie generische Ansichten verwenden? Sie könnten Ihre generische Ansicht mit Ihrem eigenen Code umhüllen und die ursprüngliche generische Ansicht in dieser Funktion mit dem modifizierten Kontext aufrufen. Auf diese Weise haben Sie denselben Vorteil wie oben - Ihre Vorlagen haben die Daten sofort zur Verfügung. Wenn Sie viele View-Funktionen haben, die alle die gleiche Kontextanreicherung benötigen, können Sie Ihren Wrapper als Dekorator schreiben - und einfach die generischen Ansichten dekorieren und diese dekorierten Funktionen in Ihren urlpatterns verwenden.
Aber was, wenn auch das Umhüllen keine Lösung ist? Gibt es nicht eine Möglichkeit, komplexeren Code zu schreiben, ohne all dieses Umhüllen? Natürlich gibt es das! Die Antwort sind benutzerdefinierte Vorlagentags. Das mag zwar ein bisschen übertrieben klingen, aber glauben Sie mir, das Schreiben einiger Vorlagentags ist wirklich nicht so schwer. Es gibt Dokumentation zur Verwendung und Erweiterung des Vorlagensystems in Python
Ein noch einfacherer Weg, Ihre eigenen Tags zu schreiben, ist die Verwendung der "simple_tag" oder "inclusion_tag" Hilfsprogramme in django.template.Library. Diese Funktionen ermöglichen es, einfache Tags sehr einfach zu erstellen - das inclusion tag basiert auf einem Vorlagensnippet, sodass Sie es als eine Vorlagenfunktion mit Parametern betrachten können. Eine Menge von benutzerdefinierten Vorlagen wird in den contrib/admin Sachen verwendet.
Das Hauptproblem mit den neueren Dingen im Code ist, dass die Dokumentation fehlt. Hoffentlich wird das mit der Zeit gelöst. Aber bitte, wenn das nächste Mal jemand versucht, Ihnen zu sagen, dass die Django-Vorlagensprache zu primitiv ist, glauben Sie ihm nicht. Die Django-Vorlagensprache ist leicht für Nicht-Programmierer zu verstehen - aber sie ist sehr erweiterbar für Python-Programmierer. Und Sie erweitern sie in der Sprache, die Sie mögen - in Python.
lambda bleibt in Python
Let's just keep lambda - GvR gibt auf
Mandelbrot Set - Labix - Beispielsource der mit PyGame Apfelmännchen auf dem Nokia Tablet malt.
Guido van Rossum und Web-Frameworks
Guido van Rossum fragt nach Webframeworks - an sich nix spannendes. Er hat halt bisher damit nix gemacht und will sich mal informieren. Stellt einige Behauptungen auf, die nicht ganz stimmen (z.B. das Djangos Templatesprache ähnlich zu PHP wäre), ist aber bei der wohl vorliegenden Kürze des "anguckens" verzeihlich.
Lustig wird es in den Kommentaren zu seinem Beitrag. Berge von Frameworks, die alle nicht fertig sind. Haufenweise Kommentare der Art "nimm XYZ, das ist toll und in den nächsten Monaten wird es bestimmt brauchbar" - ganz besonders häufig kommt das bei TurboGears als Vorschlag.
Sorry, was? Wenn ich ein Web-Framework suche, dann suche ich keines, das in ein paar Monaten benutzbar wird. Dann will ich eines, das jetzt und heute benutzbar ist und für das es jetzt und heute klare Aussagen zur Fitness gibt. Wir brauchen wirklich nicht noch mehr Webframeworks die nicht fertig werden.
Ich hab ja nix gegen Vielfalt an Frameworks - das macht das Leben spannend und interessant, weil man nie weiss, ob man auf das richtige Framework gesetzt hat - aber unfertige Frameworks die von ihren Benutzern gepitched werden als wären sie das beste seit geschnittenem Weissbrot gibts wahrlich mehr als genug.
Übrigens benutze ich genau aus diesen Gründen auch Django: das Zeug ist schon geraume Zeit im Einsatz und hat bewiesen, das es für grosse Sites und hohe Last geeignet ist. Es wurde aus echten Anwendungen rausgearbeitet und ist nicht das Nebenprodukt eines unwichtigen Web2.0-Dingens von dem ich außerhalb der TurboGears-Clique noch nie gehört hab. Es wurde auch nicht von einem Kid alleine zusammengedengelt, der sich für den neuen Einstein hält und meint das nur er weiss wie Frameworks zu sein haben. Und es ist auch kein Projekt, das im Prinzip schon seit über einem Jahr tot ist, weil der Autor selber schon längst was anderes macht. Und es wird nur deshalb als 0.9 derzeit bezeichnet, weil API-Änderungen und Aufräumarbeiten in den Innereien anstehen (was bei jedem Projekt das zwei Jahre lang im Lifebetrieb entwickelt wurde angebracht wäre) - nicht weil es nur zu 90% fertig wäre.
Natürlich wird jetzt nach diesem Artima-Beitrag alles auf GvR gucken und warten was er nimmt. Und natürlich springen alle Webframework-Autoren auf und ab und wollen sich bemerkbar machen. Und natürlich wird jedes Wort analysiert und dem anderen unter die Nase gerieben. Und eine ganze Reihe von Projekten werden kurzfristige Schnellschussänderungen machen, weil sie hoffen das GvR ihr Framework wählt. Was alles eine wirklich wahnsinnig sinnvolle Zeitverschwendung ist. Manchmal gehen mir diese Kinder in den OSS Projekten tierisch auf den Senkel.
PythonForMaemo - Python for Maemo - Python auf dem Nokia 770 Tablet (die Versandbestätigung ist heute eingetroffen, hoffentlich trifft auch das Gerät bald ein) benutzen.
twill: a simple scripting language for Web browsing - in Python scriptfähiger Web-Client. Interessant für automatisierte Seitenabrufe und für spezialisierte Robots. Möglicherweise auch für das Testen von Webanwendungen.
pyvm home - eine weitere Python-Implementierung. Ein eigener Bytecode-Interpreter und ein Python-Compiler, der in Python geschrieben ist. Klingt fast wie PyPy meets Parrot - allerdings unter Beibehalt des Python Bytecodes.
A list of open-source HTTP proxies written in python - eine ganze Reihe davon sind immer noch aktiv, und eventuell durchaus für den mobilen Einsatz interessant (speziell die auf asyncore aufbauenden, wegen der geringen Resourcen)
WebCleaner - a filtering HTTP proxy - absolut High-Tech, das Teil. Asyncore, also niedrige Resourcen, integrierter JavaScript-Interpreter gegen Obfuscation und noch einen Haufen anderer Features. Klingt von der Papierform sehr gut.
Hurring.com: Code: Python: PHP Serialize implemented in Python - PHP-Daten von Python deserialisieren. Könnte interessant sein, wenn ich weitere Sites von PHP auf Django umbauen will und z.B. an Wordpress-Settings dran will.