Mailman 3 August 2007 - lxml - The Python XML Toolkit

[lxml-dev] lxml has its page on launchpad
by Stefan Behnel 10 Apr '23

10 Apr '23

Hi all, I added the lxml project to launchpad, the Ubuntu Bug-Tracker. It also has a FAQ engine and a couple of other goodies. https://launchpad.net/lxml It's easy to sign up for launchpad, BTW, no 90%-footnotes-contract. Have fun, Stefan

9 9

[lxml-dev] Building LXML Trunk
by Sidnei da Silva 30 Aug '22

30 Aug '22

Hi, I've tried to build lxml from trunk today, on Win32. Got the following error: src\lxml\etree.c(880) : error C2059: syntax error : ')' src\lxml\etree.c(881) : error C2059: syntax error : ')' src\lxml\etree.c(882) : error C2059: syntax error : ')' src\lxml\etree.c(883) : error C2059: syntax error : ')' Any clue? Smells like a Pyrex issue? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214

4 4

[lxml-dev] Pickling objectified trees
by Christian Zagrodnick 09 Jun '08

09 Jun '08

Hi, the other day I had to pickle objectified trees. I just thought to share my findings. Pickling is about serialization. IMHO the natural serialization of an objectified tree is its XML representation. So the following basically does that: -------------------------- import copy_reg import lxml.etree import lxml.objectify def treeFactory(state): """Un-Pickle factory.""" return lxml.objectify.fromstring(state) copy_reg.constructor(treeFactory) def reduceObjectifiedElement(object): """Reduce function for lxml.objectify trees. See http://docs.python.org/lib/pickle-protocol.html for details. """ return (treeFactory, (lxml.etree.tostring(object), )) copy_reg.pickle(lxml.objectify.ObjectifiedElement, reduceObjectifiedElement, treeFactory) ----------------------------------------- You might consider just registering the reduce function in lxml itself. Shouldn't hurt, should it. -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891

2 4

[lxml-dev] lxml namespaces
by Maxim Sloyko 19 Feb '08

19 Feb '08

Hi All! I have a little problem with XML namespaces. In my application I have two XML processors, that process the same document, one after the other. The first one looks for nodes in 'ns1' namespace, and substitutes them, according to some algorithm. After this processor is finished, it is guaranteed that there are no more 'ns1' nodes left in the tree. 'ns1' namespace dclaration is still there, in the root node (well, I put it there manually). Now, when this namespace is no longer needed, I want to get rid of it, because it confuses some other processors (namely, my browser) So, the question is, how do I do that? del tree.getroot().nsmap['ns1'] does not seem to do the trick :( Thanks in advance and Happy Holidays! -- Maxim Sloyko

3 5

[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] _elementpath.pyc and py2exe problem
by Werner F. Bruhin 31 Aug '07

31 Aug '07

Hi Greg, Greg Willden wrote: > Hi Werner, > I tried that. No go. > I added an includes "_elementpath" but it didn't work. > I have an includes "lxml" as well but it doesn't fix it either. I haven't used lxml for some time and don't have it installed on this machine. IIRC lxml is a package, so if _elementpath is under it using the packages option of py2exe should do the trick - I use it for other packages (e.g. matplotlib). Werner

2 1

[lxml-dev] _elementpath.pyc and py2exe problem
by Greg Willden 31 Aug '07

31 Aug '07

Hi All, This is probably a question for py2exe developers but I'll ask it here too. I am trying to build a win32 .exe file with py2exe and it appears that py2exe cannot locate _elementpath.pyc correctly. The file does not get copied into the library.zip file. I can manually (or programatically with python's zipfile module) add _elementpath.pyc to the zip file and then the application works fine. Has anyone experienced this? Any ideas why? Thanks Greg -- Linux. Because rebooting is for adding hardware.

3 3

[lxml-dev] ERESTARTNOHAND error
by Frédéric Mantegazza 31 Aug '07

31 Aug '07

Hello, Some months ago, I migrated some part of our code from libxml2/libxslt modules to lxml module (which is much pythonic!). But my code never worked, because of a seg. fault :o( The crash occurs at: result = self.__xslFilter.apply(tree, {'filename':"'%s'" % baseName}) This code is used inside a Pyro server (Pyro is a client/server framework. see http://pyro.sourceforge.net), so in a multi-threaded environement. I ran the server using strace to see what happens: I got a ERESTARTNOHAND error. This error is very strange, and Google does not give usefull informations... I tested my code out of Pyro: it works. I made a simple Pyro serveur with just this part of the code: it works too. It only crashes when using the real server, which uses a lot of multi-threads calls. Another guy had a similar problem, but the error was in the python mysql client wrapper, only on stressed usage. It seems that there is a problem in either lxml and pymysql when used in a stressed multi-threaded way. I use locks in my server to avoid re-entrant calls to lxml, so I'm sure the problem is not there; I feel that it is related to the number of threads running... Does anyone has an idea of that problem? Thanks, PS: I also use lxml from mod_python, and all is working fine. -- Frédéric

2 8

[lxml-dev] should _setElementValue add type attributes?
by jholg＠gmx.de 28 Aug '07

28 Aug '07

Hi, I discussed this with Stefan before and I'm anxious to know if this is the way to go (maybe as switchable behaviour), removing the need for a beast like the discussed PT() factory, as well as making type behaviour arguably more "straightforward", at the cost of auto-adding py:pytype attributes: # _setElementValue implementation that auto-adds type(RVAL).__name__ as # py:pytype cdef _setElementValue(_Element element, value): if value is None: cetree.setAttributeValue( element, XML_SCHEMA_INSTANCE_NIL_ATTR, "true") elif isinstance(value, _Element): _replaceElement(element, value) else: cetree.delAttributeFromNsName( element._c_node, _XML_SCHEMA_INSTANCE_NS, "nil") if not python._isString(value): pytype_name = type(value).__name__ if isinstance(value, bool): value = _lower_bool(value) else: value = str(value) else: pytype_name = "str" cetree.setAttributeValue(element, PYTYPE_ATTRIBUTE, pytype_name) cetree.setNodeText(element._c_node, value) I'm +1 for that. By making it switchable we could cater for those who don't care about the types that much but who do not want to see any non-explicitly created attributes. Holger -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

2 6