Mailman 3 September 2007 - lxml - The Python XML Toolkit

[lxml-dev] lxml 1.3.4 released
by Stefan Behnel 04 Sep '07

04 Sep '07

Hi all, I just released lxml 1.3.4 to PyPI. It has a minor bug fix and a few compatibility enhancements both backwards and forwards. Changelog follows. One of the changes is that the exception that 1.3.3 raised for tag names containing a ':' was changed into a warning. lxml 2.0 will be strict here. Have fun, Stefan 1.3.4 (2007-08-30) Features added * The ElementMaker in lxml.builder now accepts the keyword arguments namespace and nsmap to set a namespace and nsmap for the Elements it creates. * The docinfo on ElementTree objects has new properties internalDTD and externalDTD that return a DTD object for the internal or external subset of the document respectively. * Serialising an ElementTree now includes any internal DTD subsets that are part of the document, as well as comments and PIs that are siblings of the root node. Bugs fixed * Parsing with the no_network option could fail Other changes * lxml now raises a TagNameWarning about tag names containing ':' instead of an Error as 1.3.3 did. The reason is that a number of projects currently misuse the previous lack of tag name validation to generate namespace prefixes without declaring namespaces. Apart from the danger of generating broken XML this way, it also breaks most of the namespace-aware tools in XML, including XPath, XSLT and validation. lxml 1.3.x will continue to support this bug with a Warning, while lxml 2.0 will be strict about well-formed tag names (not only regarding ':'). * Serialising an Element no longer includes its comment and PI siblings (only ElementTree serialisation includes them).

4 5

[lxml-dev] objectify factories
by Stefan Behnel 03 Sep '07

03 Sep '07

Hi Holger, I finally looked a little closer at the latest patches you sent me. They contain good ideas, but I'm still not very comfortable with the implementation. I think the PT() factory should be folded into DataElement(), as it's just a special case. I attached a patch that merges a part of your latest factory patch and removes the need for the PT factory. Please check if it does what you wanted and if anything is still missing. Regarding the TypedElementMaker, I think that if we write one that is adapted to objectify, we should not stop half-way. We should remove the "typemap" thing and just use the type inference mechanisms that objectify already provides. You can take a look into that, if you want, otherwise I will try to come up with an implementation when I find the time (which may be after the release of 2.0alpha1). Holger, is this ok for you or is there any reason we should not go this way? Stefan

2 14

Re: [lxml-dev] [XML-SIG] lxml 2.0alpha1 released
by Stefan Behnel 03 Sep '07

03 Sep '07

Hi, Gloria W wrote: > Stefan, congratulations. This is definitely useful. Thanks! :) > Please talk a bit about the API, and how it differs/varies from > cElementTree, http://codespeak.net/lxml/dev/compatibility.html > or link to some examples. The docs are full of doctest examples. However, as lxml.html is still pretty new, its docs are not as comprehensive as those for lxml.etree yet. > For example, the node nesting, > the usage of a 'tail' for trailing text. I wonder if lxml offers more of > a DOM compliant node nesting, or if it conforms to the > conventions/oddities of ElemenTree. lxml.etree aims for ElementTree compatibility, so these things work alike. The above link describes the differences that we either cannot work around for technical reasons (or performance reasons) or that are considerate decisions where we think ElementTree is wrong. Note that the ElementTree API is more and more becoming a basis for other APIs in lxml. There is lxml.objectify, which replaces a lot of this API by something that works more like Python objects themselves (a data binding approach). lxml.html extends the API with a bunch of helper methods for link handling and also changes the way the serialisation works to better adapt it to HTML. There's also MathDOM, a MathML implementation, which was the original reason for making lxml extensible at the Element level, back in the days of lxml 0.7. The original idea was actually 'stolen' from Xist, although lxml has definitely found its own way of dealing with it. The one thing I like most about lxml is the tool integration. For example, you can use the Element API in lxml.etree or lxml.objectify or lxml.html, with any of the five path languages: ElementPath, ETXPath, XPath, CSS-Selectors or ObjectPath. I think this is a trend that should continue. Most XML/HTML formats can benefit from specialised Element classes with specially adapted or added methods, properties and even different tree behaviour, while still taking advantage of all the other tools that lxml provides. The possibilities that lxml offers here are close to unlimited (both at the Python level and at the C level) - even with the 'oddities' (as you called it) of ElementTree. I personally believe that .tail attributes are actually a big advantage, as the ignorance of text nodes simplifies the tree model considerably (well, the public one, not necessarily the internal one...) > Also show us how it differs from BeautifulSoup, which has extremely > robust unicode handling and mangled XML/HTML tag completion, but may > benchmark a bit slower. libxml2 does not have as robust support for HTML-like tag soup as BeautifulSoup, but it does a pretty good job anyway. In lxml 2.0, lxml.html comes with BeautifulSoup integration (as ElementTree does), so now you can have both: a tag soup parser and all the features of lxml. Stefan

1 0