NLTK Home (Natural Language Toolkit) - und wenn es etwas leistungsfähiger und flexibler werden soll, das hier ist sozusagen der Bauchladen für Parser. Fokus liegt auf der Analyse natürlicher Sprachen, daher auch so Sachen wie Stemmer (Stammfindung für Wortformen) enthalten. Könnte aber für einfache eingebettete Sprachen dann doch eher Overkill sein.
Python Package Index : Esrapy 0.5 - ein Parser und Lexer Toolkit komplett in Python. Könnte später mal interessant werden in einigen Projekten, zumindestens für kleinere Konfigurationssprachen.
Building Skills in Python - Online-Buch über Python für Programmierer, die einfach die Sprache noch nicht kennen. Sieht sehr gut gemacht aus, auf den ersten Blick.
Oscar für Waltz - absolut verdient. Der Mann war für mich die perfekte Besetzung in Tarantinos Film.
Jobo AG & Jobo Labortechnik GmbH sind insolvent (aktualisiert) | photoscala - na toll, ich hab mir ja auch erst letztes Jahr einen Jobo Bildertank gekauft, da werden dann möglicherweise Firmware-Updates in der nächsten Zeit problematisch. Ok, ich hab nicht vor mir in der nächsten Zeit neue Kameras zu kaufen (hab ja gerade erst mein System renoviert), aber trotzdem ...
hugoduncan's clj-ssh at master - GitHub - ziemlich interessante Bibliothek, die ssh-Zugriff in Clojure-Scripten ermöglicht. Zum Beispiel für Serverautomation sehr interessant. Benutzt Jsch, eine Java-native ssh-Bibliothek (also kein Umweg über shell-pipes oder ähnliches).
clojure-python - interessantes Projekt das die Interoperabilität zwischen Jython und Clojure vereinfachen will und auf einen ähnlichen Level heben will, wie sie zwischen Clojure und Java schon ist. Besonders interessant für mich, weil es mir dann erlauben würde, stärker auf Clojure als Alternative zu setzen - Jython ist schon geplanter Baustein der Werkzeugkiste, hat aber einige Performance-Probleme die Clojure durch direktere Java-Integration nicht hat. Ausserdem schreib ich lieber kompakten Lisp-Code als geschwätziges Java ...
Scala: Post-Functional, Post-Modern, or Just Perl++? - interessanter Post der einige der Punkte aufgreift die mich auch bei der Betrachtung von Scala stören. Ich mag besonders die Bezeichnung als Perl++, denn das ist genau der Eindruck der sich mir aufdrängt immer wenn ich in Scala tiefer einstiege. Auch Perl hat mich immer fasziniert, aber spätestens als ich größere Projekte damit gebaut habe und die advanced Features von Perl intensiver benutzt habe, kamen mir dann doch so einige Zweifel über die Wartbarkeit des Ergebnisses - ganz besonders unter dem Aspekt die Arbeit einem meiner Kollegen zu übergeben für die weitere Betreuung. Damals habe ich den Wechsel zu Python durchgezogen, weil es mir viele der Features in einem wesentlich saubereren Sprachkonzept geboten hat. Ich glaube das könnte auch erklären warum ich mit Scala einfach nicht warm werde, auch wenn vieles davon mich fasziniert.
Bottle: Python Web Framework - super-simples Python-Web-Framework das als ein einzelnes Python-File daherkommt. Keine Abhängigkeiten außer von der Standardbibliothek. Kein integrierter ORM, aber dafür sehr schlank und vielleicht gerade für Projekte interessant bei denen man eh keine Datenbank braucht oder will (oder das Dateisystem als Datenbank benutzt).
digg's lazyboy at master - GitHub - weil key-value-datastores im Moment total der Hype sind (und weil sie wirklich für manche Sachen praktischer sind als klassische Datenbanken), werd ich mir wohl Cassandra angucken. Einfach weil es nach Berichten im Web die besten Skalierungsmöglichkeiten bietet. Und weil es in einigen großen Websites im Einsatz ist - speziell zum Beispiel bei Digg (das ich als Site zwar doof finde, aber hey, die haben ordentlich traffic und laufen relativ stabil) mit lazyboy als Python-Anbindung.
rfc1437 / lazypy / source — bitbucket.org - und noch ein Projekt von mir (wieder) online. Lazypy ist eine kleine Bibliothek die lazy evaluation und futures (thread und process basiert) für Python verfügbar macht. Sehr praktisch für die einfache Programmierung von Nebenläufigkeit. Ok, man kann alles auch von Hand machen, aber ich mag halt den etwas funktionaleren Ansatz lieber. Ist eigentlich aus 2004, aber ich habs mal modernisiert (die prozess-basierten Futures zur Umgehung des GIL) und neu hochgeladen.
17.6. multiprocessing - viel besser als externe module für Prozess-Kommunikation sind die seit Python 2.6 mitgelieferten Tools in multiprocessing.
Semanchuk.com - Python IPC Modules - inter-prozess-Kommunikation mit Python.
LinuxTuples - ein Tuple-Space Server für Linux, in C geschrieben, aber mit Python-API. Sollte ich mir mal näher angucken, könnte interessant für verteilte Apps sein. Wobei ich ja lieber eine python-lokale Implementation auf Basis von Standard-Prozess-Kommunikationsmitteln hätte, um vernünftiger mit multiprocessing in Python arbeiten zu können. Gerade für einfache Tools oder Webapps wäre es einfacher manche Sachen direkt vom dort zu forken und dann über TupleSpaces zu kommunizieren. Aber dafür immer gleich einen extra Server zu starten, das ist es irgendwie auch nicht.
Johnny Cache v0.1 documentation - unbedingt mit einem Projekt in der Firma mal ausprobieren, denn das Modell ist ziemlich heftig und ich könnte damit ein paar der Probleme elegant lösen für die ich derzeit Sonderlösungen habe. Ist auch ziemlich ähnlich zu meinem ersten Ansatz für dieses Problem (allerdings habe ich die grössten Performance-Probleme jetzt durch redundante Datenhaltung und automatische Updates an Objekten ebenfalls recht elegant gelöst).
