Martijn Faassen wrote: > As the original author of lxml I might have a few comments.
Hi :) > xml.minidom > > API: standard-ish as DOM, but is not very Pythonic > Performance: slow in comparison, gobbles up memory > Features: just a tree, that's it. > Ease of installation: in standard library But very slow. It could be used for fxd files because they are small. Huge tasks like XMLTV is a no go. In kaa we use it for the config.cxml files which are very small. > xml.sax > > API: standard as SAX, but very low-level so relatively hard to work with > Performance: high - I haven't measured the SAX parser in the standard > library, but it's probably more than adequate for most purposes. Low > memory usage. > Features: almost nothing, just low-leve SAX events > Ease of installation: in standard library SAX is used in kaa when the whole DOM is not needed. E.g. kaa.epg uses SAX to parse the XMLTV file. There is no need to keep everything in memory, only one programm and we put it into the db. If the complete tree is needed, SAX is a no-go. > ElementTree > cElementTree: > lxml For Freevo this may be the best choice. If we only use the ElementTree API, we could check for all three in the order of performance (I guess the list above in reverse order). So the user needs only one extra package installed. > Features: tons of features. xpath is *very* useful when reading in XML. > XSLT, schemas, fast messy HTML parser support, etc. I do not think we need that. > Ease of installation: harder. C compiler needed (except on Windows). > libx2ml/libxslt installation needed (except on Windows, it's bundled). > On Linux usually installation is easy enough as C compiler is available > and recent enough version on libxml2 is typically installed. On Mac OS > they install a version that is some years old and too old, so more > installation effort is needed. That is the problem of the distro. If all distros have lxml I have no problem with making it a requirement. Duncan: what parts of Freevo need XML? > For your purposes, I think (c)ElementTree is a good bet, but if you need > a lot of features (which can be very convenient to have around), try > lxml. I'd avoid MiniDOM, though it's probably not a disaster if > performance is unimportant. If you have huge XML files to parse and you > need a stream-based parser, you may want to see whether iterparse in > ElementTree (or lxml) is a more convenient approach than SAX. > > http://effbot.org/zone/element-iterparse.htm I have a question about that one. I'm writing an XMPP module for kaa and I'm looking for a good XML lib. The problem: I get the strings From a socket and they may not be complete. iterparse can work with that. BUT the tree will NEVER be complete, the last closing element </stream> will be at the end of the conversation. That is why I use SAX, but maybe lxml could also be handy. Dischi -- A man with a watch knows what time it is. A man with two watches is never sure.
pgpxHgRXSNq82.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
