[lxml-dev] Call for contribution towards lxml 1.3

[jholg at gmx.de]

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