[lxml-dev] iterparse support ?
Hi list, Is there any plan to add the 'iterparse' method (or some kind emulation) of emulation to lxml.etree? I don't really know libxml2 but it should be possible to reproduce the iterparse semantics by using libxml2's SAX API, shouldn't it? Apparently, the yum developpers (the fedora package manager) found this missing feature to be a decisive drawback that prevented them to switch from ElementTree to lxml.etree: https://www.redhat.com/archives/fedora-devel-list/2005-May/msg00328.html I also wanted to implement a lxml.etree based XML parser plugin for rdflib, but I guess it's not wise to load all the XML tree in memory before actually constructing the RDF graph. BTW, the missing iterparse method should be mentionned on http://codespeak.net/lxml/compatibility.html Best, -- Olivier
Olivier Grisel wrote:
Hi list,
Is there any plan to add the 'iterparse' method (or some kind emulation) of emulation to lxml.etree? I don't really know libxml2 but it should be possible to reproduce the iterparse semantics by using libxml2's SAX API, shouldn't it?
I don't have any plans myself but I gladly accept patches! I'm sure it's possible to replicate the semantics using libxml2's SAX or reader support. I haven't really explored libxml2's streaming APIs nor iterparse yet. I know libxml2 even has support for validating streaming and such using RelaxNG; it'd be nice to be able to support something like that too.
Apparently, the yum developpers (the fedora package manager) found this missing feature to be a decisive drawback that prevented them to switch from ElementTree to lxml.etree:
https://www.redhat.com/archives/fedora-devel-list/2005-May/msg00328.html
I also wanted to implement a lxml.etree based XML parser plugin for rdflib, but I guess it's not wise to load all the XML tree in memory before actually constructing the RDF graph.
BTW, the missing iterparse method should be mentionned on http://codespeak.net/lxml/compatibility.html
It does: Some of the API of ElementTree has not yet been implemented and is thus missing in lxml.etree. Feel free to help out! But I'm glad you consider this to be the last bit of ElementTree that's left to implement. :) Regards, Martijn
participants (2)
-
Martijn Faassen
-
Olivier Grisel