[lxml-dev] Re: Call for Contribution: lxml 0.9

Hi Stefan. Thanks for the work on this and sending the heads-up note. Before writing and checking in a test, I want to find out if something is known behavior. I have an XSLT that uses XML data in the stylesheet itself. Essentially: ---- xslt preamble stuff ---- <localstuff> <localitem>klkdk</localitem> </localstuff> .....later.... It works with xsltproc but doesn't work with lxml. I wonder if there's something about the resolver that is the issue. Should I file a case for this, or is this known behavior? Also, I'd file a case about not wiring in libxml2's HTMLParser, but I suppose that's not a bug, it's just a missing feature. :^) I *really* need that wired in at some point, but for now, I can just ship some other tool that converts HTML -> well-formed XML. --Paul Stefan Behnel wrote:

Hello, everyone!

Martijn and I realised that there has not been a release of lxml for quite a while - despite a lot of important changes to the code base.

We therefore agreed to prepare the release of lxml 0.9 for

*Monday, March 20*.

The remaining time will be used to get the trunk ready for a release. It will include the current feature set of the trunk plus the support for extension functions that is currently implemented in the scoder2 branch. The latter still needs a bit of discussion and merging. Any comments on this are appreciated.

For you, this announcement means the following.

- If you want any features included, make sure you send requests and patches to the list within the next days or try to fix a date when a patch will be available. Remember that we may have to discuss patches before applying them.

- If you feel that you especially like or dislike anything about the new features and the way they are made available through APIs, feel free to tell us over the list.

- If you feel that anything from past discussions has been left out that should be worth remembering for a new release, speak up now.

- We know that there are still a few places where documentation would help users to understand new features. A good way to contribute would therefore be to look through the documentation in the "doc" directory and see if it is understandable or if there is anything you might want to add.

- In the same line, usage examples in the form of doctests would be nice to have for more API functions. They also belong into the files in the "doc" directory, which are (or must be) called from the related test cases in src/lxml/tests.

Happy coding, Stefan