Hi Stefan, hi all,

lxml 1.3 is nearing completion. There were some major changes under the hood,

Is there a planned release date? Do you plan to get the xsi:type="xsd:<type>" thingie into 1.3? I'd love to have this in and I might be able to contribute if needed, but would have to know how much time left until the final 1.3 release; because I certainly will not be able to do so until the end of next week.

[...] But there is another area where help is appreciated. A very important area in fact: *documentation*. While there is quite a bit of documentation both on ElementTree and lxml, there are certainly places where lxml's API and its way of doing XML are hard to access, especially for new users and those who have a fixed (should I say: Java-ish?) mindset on XML. If you want to contribute, helping out in this area is warmly appreciated. Here are a few ideas that would be truely helpful for lxml's user base.

* I would love to see lxml's own tutorial that gets the main ideas and the most useful features across without caring too much about ElementTree (which already has a tutorial).

I do have kind of a tutorial introduction to lxml.objectify, but we tend to wrap some of the entry points into our custom API, and we use some extensions (namely datetime and decimal, so this does currently not match 1-to-1 to out-of-the-box objectify. As the official objectify documentation is kind of tutorial-like itself, maybe I could check where I could add enhancements to that. Regarding API documentation I vote for some reference doc that is actually generated from docstrings or source code documentation. What about pydoc?

* Some statistics: what /are/ the most useful features of lxml? What do people like or use most? What parts of lxml should be more accessible? Which parts are so well done that people grasp their usage immediately (and should therefore be promoted as an eye-catcher)?

For me, that's 1. standards-compliance by intelligently building on libxml2/libxslt 2. feature-richness: covers extremely convenient XML handling plus Schema/RelaxNG validation and XSLT 3. stability and maturity 4. extensibility 5. performance

* We could benefit from a Wiki where users could contribute code examples, best practices, work-arounds or tool snippets. We should also start linking to external pages, blogs, presentations on lxml or ElementTree that others might find interesting.

A wiki would be nice. I really think lxml has the potential to be THE python XML toolkit. The only thing users might keep from it sometimes is the dependency on the massive libxml2, which can be addressed by a good build/dependency system. And, as said, building on libxml2 is of course also lxml's biggest advantage. Btw I for one don't like eggs; I like to package libraries in my platform package format. Anyone know about a tool to convert an egg to a Sun package? Keep up the superb work, Holger -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

jholg@gmx.de wrote: [snip useful thoughts]

Btw I for one don't like eggs; I like to package libraries in my platform package format. Anyone know about a tool to convert an egg to a Sun package?

Converting eggs themselves, I don't know. Distutils/setuptools is able however is pluggable and should have the information to build all kinds of package formats, including tarballs, eggs, and rpms. This would be the right area to look into to get native package support. In addition, the zc.buildout infrastructure that I experimented with in the past does provide nice ways to get a lxml set up which includes libxml2 and so on. Unfortunately it only makes sense if you develop the rest of your application as a buildout. zc.buildout is rumored to be growing support for RPM-based deployement and such, so that might be something else to explore. Regards, Martijn

On 2007-04-26 22:19:14 +0200, Stefan Behnel said:

Hi all,

lxml 1.3 is nearing completion. There were some major changes under the hood, but the most visible part of the new release is actually the new layout of the documentation site, which should make it much more accessible. As usual, the preview is here:

http://codespeak.net/lxml/dev/

Some of you have mentioned their impression that it's hard to help out on lxml as it's written in Pyrex, not Python. Although the current code looks very C-ish in many places, this is more of a performance optimisation than a real requirement. Pyrex actually makes it possible to work on the code in a very Python-like style, and to make the C-ification a matter of later improvement. So Python(-like) implementations of new features are definitely welcome. A non-optimised implementation of an interesting feature is much better than the lack of this feature would be. So, everyone is invited to get involved in making the code even better than it is today.

The problem for me always was that the Pyrex required was some special version. And if you'd just checkout the code you couldn't compile it just like that. If there's a way to "fix" that (like with a buildout) I'd be very willing to do changes, even in Pyrex. Pyrex doesn't look too strange to me. :) -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891

Stefan Behnel writes:

Here, it's actually sufficient to checkout the "Pyrex" directory under the lxml source tree, i.e.

svn co http://codespeak.net/svn/lxml/trunk lxml cd lxml svn co http://codespeak.net/svn/lxml/pyrex/Pyrex Pyrex

That has the additional advantage that you can "svn up" both with a single command.

You need to edit the svn:externals property so Pyrex gets updated as well. You can do the following. svn co http://codespeak.net/svn/lxml/trunk lxml svn ps svn:externals "Pyrex http://codespeak.net/svn/lxml/pyrex/Pyrex" lxml svn up lxml This we everything gets updated, when you do a "svn up". Maybe it makes sense to put svn:externals in trunk, since people who checkout from trunk need Pyrex anyway. Kind regards, Michael