Mailman 3 June 2007 - lxml - The Python XML Toolkit

Re: [lxml-dev] tests crash on libxml2 2.6.19 - drop support?
by Stefan Behnel June 20, 2007

June 20, 2007

Hi, Mike Meyer wrote: > In <46793138.4040701(a)weitershausen.de>, Philipp von Weitershausen <philipp(a)weitershausen.de> typed: >> I hear that others have lxml working on MacOS quite nicely. Not sure >> whether this is with MacPorts or self-compiled libxml/libxslt (last time >> I tried the latter I had no luck either). Martin Aspeli and Christian >> Zagrodnick were the last ones I heard report success in some way or >> another... > > I've had no trouble with lxml built from Macpors on OSX. Ok, so that sounds like people rather install new libs, which makes it rather unlikely that they end up trying to use something older than 2.6.20 anyway. So, if we drop the support, we explicitly tell people to install something newer, which is in their own interest. > Well, except > for the previously reported and otherwise uncommented on problem with > XInclude, but that's reproducible under FreeBSD, and with > cElementTree. An XInclude problem that's reproduceable with cElementTree (which has no real XInclude support) would most likely have been commented on. Any more hints on what you are talking about here? Maybe ElementInclude? Are there any issues with it? Stefan

1 0

[lxml-dev] tests crash on libxml2 2.6.19 - drop support?
by Stefan Behnel June 20, 2007

June 20, 2007

Hi all, when going through my usual little pre-release QA test scripts, I noticed that the tests on the 1.3 branch currently trigger a reproduceable crash under libxml2 2.6.19. Don't know about older ones as they don't even compile on my machine. Sadly, valgrind doesn't tell me enough about where the problems come from, so it's not a quick thing to fix. Now, there are two ways to tackle this: work around the problem or drop support for 2.6.19 and earlier. Given the fact that the release of 2.6.20 just had its second anniversary (and knowing that libxml2 still had a lot of bugs fixed since), I do not feel much in favour of the first solution. I would rather encourage people to upgrade their libs if they want to use lxml 1.3. This is not a problem for most Linux systems where installing new libs tends to be trivial (and is often done on a regular basis to fix security holes). Neither is it a problem for Windows as long as Sidnei keeps providing us with static builds against recent libs. But I remember that MacOS X usually ships with pretty old versions, and I think I recall one of them being 2.6.16 and the other being 2.6.19. So taking this decision would mean dropping out-of-the-box support for those MacOS versions. Can anyone please verify that these were the versions in question? What are the lib versions that current MacOS systems ship with? And which OS versions would we drop support for if lxml 1.3 stopped running under 2.6.19? Hoping for some insights, Stefan

3 4

[lxml-dev] XSLT crashing Zope
by Eric Tiffany June 19, 2007

June 19, 2007

I am having a really difficult time getting lxml etree.XSLT to work inside Zope. It will start up, but after a couple of requests (or sometimes immediately) python crashes with a stack trace that looks like this: Thread 2 Crashed: 0 libxml2.2.dylib 0x04504370 xmlDictFree + 265 1 libxml2.2.dylib 0x045042e2 xmlDictFree + 123 2 etree.so 0x04206d2a __pyx_f_5etree_14_ParserContext_initThreadDictRef + 63 (etree.c:20751) 3 etree.so 0x0426f761 __pyx_f_5etree_4XSLT___call__ + 2597 (etree.c:33610) 4 org.python.python 0x0020d87f PyObject_Call + 45 (abstract.c:1795) 5 org.python.python 0x0027e397 PyEval_EvalFrame + 16838 (ceval.c:3776) 6 org.python.python 0x0027ebaa PyEval_EvalFrame + 18905 (ceval.c:3651 And on for another 170 frames. This is running zope 2.9.6, python 2.4.4, on MacOS 10.4.9 (Intel) with this environment lxml.etree: (1, 3, 0, 44370) libxml used: (2, 6, 28) libxml compiled: (2, 6, 28) libxslt used: (1, 1, 20) libxslt compiled: (1, 1, 20) I have built lxml using --without-threading, and it seems to make no difference. If I test from the python shell, my example works fine. IF I RUN ZOPE INSIDE ECLIPSE, IT WORKS FINE. Same code, same setup. If I start zope using it's zopectrl or runzope scripts, it croaks. Here is the code: print >> sys.stderr, abs_execution_path("header.xsl") xsl_tree = etree.parse(abs_execution_path("header.xsl")) print >> sys.stderr, "creating transformer" transformer = etree.XSLT(xsl_tree) print >> sys.stderr, "parsing header" header = etree.parse(StringIO(str(context.response))) print >> sys.stderr, "transforming header" result = str(transformer(header)) print >> sys.stderr, "result done" And here is what I see in the log /Applications/Plone-2.5.2/Instance/Products/xtend/header.xsl creating transformer parsing header transforming header Segmentation fault This is costing me a lot of $$ and lost goodwill from my customer. I wish I had never heard of python or plone. ET

2 1

Re: [lxml-dev] lxml 1.3 coming up
by Stefan Behnel June 19, 2007

June 19, 2007

Stephan Richter wrote: > Did sourceline make it? :-) Right now z3c.rml depends on lxml trunk, since the > lxml 1.3 beta release does not contain the sourceline feature. It would be > nice to depend on a release. Well, you can check: http://codespeak.net/svn/lxml/branch/lxml-1.3/src/lxml/etree.pyx (hint: yes it did :) Have fun, Stefan

1 0

[lxml-dev] Website won't render on Camino
by Eric Tiffany June 18, 2007

June 18, 2007

The http://codespeak.net/lxml/ site doesn't render on Camino Version 2007050909 (1.5). The current contents of the browser just remains (as if you had not tried to follow a link or didn't put in a new URL). It's very weird. ET

2 3

[lxml-dev] list-like views?
by Ian Bicking June 18, 2007

June 18, 2007

In the atom wrapper I made, I expose a categories attribute on entries. This returns a list (-like object) of the <category> elements. It also lets you add and remove from that list to modify the entry. I generally don't do this, as it feels a little too clever to me. The list-like object isinstance(obj, list), but it's a subclass, and has a different repr. But I still worry about confusion. Anyway, I was thinking of adding something similar to HtmlElement for .classes, which would expose the HTML classes. This way you wouldn't have to have methods like has_class, add_class, and remove_class (or do it manually with string manipulation). How does this sound? The class I used is _LiveList, here: https://svn.openplans.org/svn/TaggerStore/trunk/taggerstore/atom.py -- basically it just calls some callbacks everytime something is added or removed from the list. Ian

2 3

[lxml-dev] Annoying interaction between comments and text
by Itamar Shtull-Trauring June 15, 2007

June 15, 2007

Lets say I have an element with some text in it. No subelements, just text. It may have a comment in it, but I really don't want to have to think about it. In elementtree I can just do: >>> elementtree.ElementTree.fromstring("<x>hello  world</x>").text 'hello world' But, in lxml if I do that I get: >>> lxml.etree.fromstring("<x>hello  world</x>").text 'hello ' One needs to use xpath to extract all the text. This is problematic because it means you can basically *never use the text attribute of elements*, since someone may have added a comment. Since comments have no semantic meaning this is something of a problem. I bet there's lots and lots of lxml code that would break if someone added a comment inside an element's text.

2 2

[lxml-dev] atom model
by Ian Bicking June 14, 2007

June 14, 2007

After writing a object model for Atom that serialized to and parsed from XML, I realized Atom and its XML representation really shouldn't be separated, so I created some custom elements to make it a bit easier to handle, while still using the XML as the sole source of information. I'm a little unsure what to do about the namespaces. Everything is in a namespace, but it's tedious to put in everywhere. I've put in some little helper methods internally, and mostly you don't need to use the namespace globally, but I'm unsure about it all. I've created an Element() function that automatically adds the namespace if no namespace is given; helps a little I guess. The standard ways of creating elements is a bit tedious, really. I guess builder can help there a bit, though I don't see a way to give my own parser (which I need in this case). Any suggestions about any of it are welcome. The module is at: https://svn.openplans.org/svn/TaggerStore/trunk/taggerstore/atom.py I didn't really look around in the lxml source, but I used several descriptors that could be general purpose. Maybe there's a better way to do these, or maybe they could go in lxml somewhere. -- Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers

3 5

[lxml-dev] python test.py --coverage and doctests
by Ian Bicking June 14, 2007

June 14, 2007

The coverage analyzer in test.py doesn't seem to notice stuff that happens in doctests. Is there any way around this? Ian

1 0

[lxml-dev] Renaming the drop_*() methods
by Stefan Behnel June 14, 2007

June 14, 2007

Hi Ian, Ian Bicking wrote: > Stefan Behnel wrote: >> as I was reviewing your code, I decided to rename drop_tag() and >> drop_element() to drop_element() and drop_tree() respectively. > > I don't mind drop_tree, but I think drop_element is confusing. For > instance, we both have different ideas about what it seems to imply -- > to me if feels like it should drop the element and its children. What > makes it different than .remove() I guess is that it doesn't remove the > tail Which is a good reason why drop_element() is not a good name, you are right. In ET, an Element is something with a tag, a text, children and a tail, and only the tag is removed here. So let's make it drop_tree() and drop_tag() then. > Incidentally, someone asked for a drop_tree method in another context, > and maybe it makes sense in more than just HTML. It's a tricky method > to get right, in that you can do it lazily and get it wrong (e.g., > assume the element doesn't have a tail, or assume it does and it's not > None, or that the element really has a previous sibling, or doesn't). Right. But what about helper *functions* then instead? They could work on any element, not just on those that define them as methods. Stefan PS: I'm setting the list back on CC to open this discussion for other comments.

2 4