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 Templates are not limited
shannon -jj behrens thinks that Django template language is limited - because it doesn't have functions with parameters to do html snippet reuse. Of course the official - and simplified - answer to this is, that Djangos template language is that simple by design, so that it can easily be learned by non-programmers (as often designers aren't necessarily programmers). This is a quite good reasoning, but I think it's a bit too simplified.
So here is the longer - more complete - answer to this accusition: the Django template language isn't limited at all. Yes, I know that the "include" and "block" tags aren't parameterizable and so aren't often that useful for more complex situations (at least if you don't want to end in namespace hell due to passing some template-globals in the context).
So what should you do if you notice that your templates would need more complex code? One way would be to precompute the data in the view function and pass it on via the context to the template - that way the template has the ready data and can directly present it.
But what to do if you can't precompute, because you are using generic views? You could wrap your generic view with your own code and call the original generic view in that function with the modified context. That way you have the same benefit as above - youre templates have the data readily available. If you have many view functions that all need the same context enrichment, you can write your wrapper as a decorator - and just decorate the generic views and use those decorated functions in your urlpatterns.
But what if even wrapping isn't the answer? Shouldn't there be some way to do more complex code without all that wrapping? Sure there is! The answer are custom template tags. This might sound like a bit of overkill, but believe me, writing some template tags isn't really that hard. There is documentation on using and extending the template system in python
An even easier way to write your own tags is to use the "simple_tag" or "inclusion_tag" helpers in django.template.Library. Those functions allow to build simple tags very easily - the inclusion tag will base it's output on some template snippet, so you can see it as a template function with paramerters. A lot of usage of custom templates is in the contrib/admin stuff.
The main problem with the newer stuff in the code is, there is documentation missing for it. Hopefully that will be solved over time. But please, if the next time someone tries to tell you that the Django Template Language is to primitive, don't believe him. The Django Template Language is easy to grasp for non-programmers - but it's very extensible for Python programmers. And you extend it in the language you like - 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.