Version 0.5 adds a Python binding! libextractor is a library used to extract meta-data from files of arbitrary type. It is designed to use helper-libraries to perform the actual extraction, and to be trivially extendable by linking against external extractors for additional file types.

http://gnunet.org/libextractor/

lxml is an alternative, more Pythonic binding for the libxml2 and libxslt XML processing libraries.

lxml 0.6 contains important bugfixes, in particular better namespace support while handling attributes, as well as a fix for what turned out to be totally broken behavior for etree.tostring(). An upgrade is recommended.

http://faassen.n--tree.net/blog/view/weblog/2005/05/15/0

Julien Anguenot and the folks at Nuxeo have announced a new collaboration site for a community-drive Zope3 ECM project.

This project aims to build out a number of shared components for Zope3, which would be usable as the underpinnings of CMS offerings from Nuxeo, Infrae, Zope Corporation, etc.

I will be participating in a Z3 ECM Sprint which focuses on advancing this project's goals.

I love Cringely's analyis of Sun's dilemma:

What are they to do? Their current strategy of selling processing power by the cycle is like a new car dealer renting back seats of cars on the lot to teenagers looking for a place to make out.

http://www.pbs.org/cringely/pulpit/pulpit20041216.html

Phillip chats about the problems for which Java programmers naturally turn to XML, and Python programmers to .... Python.

I particularly like Phillip on using XML:

XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think 'I know, I'll use XML.' Now they have two problems."

This is a different situation than in Java, because compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that.

Designed to work with Ultramonkey in a HA cluster, DRDB is a cheaper, less featureful cousin of RedHat's GFS.

Harry Fuecks blogs about an interesting survey of "recurring problems in projects using dynamic languages"

At the other end of the scale there's developers who know a language well and can't resist adding 'smart' features. That needs to be a golden rule of what not to do with dynamic languages - don't extend the language (at least not using the language itself).

He talks mainly about Javascript and PHP, but then points at a "nasty bit of cleverness using Python's shiny new decorator syntax."

I want it for Zope!

http://www.tarind.com/depgraph.html