About PyRXP
PyRXP claims to be the fastest Python XML parser around... but this has a price. Once XML is parsed, you get a tree structured as tuples, lists and dictionnaries. While this is very Pythonic, it's not so trivial to write/read code handling such a tree.
People at Reportlab argue about that for speed. Dealing with classes in Python is mem hungry, so they use only basic data structures (tuples,list,...). I can understand that but i believe it's an extremist point. Finding a balance between the DOM API (which is extremist too :) and such structures could turn to be more popular, maybe a Python xml_node builtin type ...
#. verbat on Mon Dec 20 18:33:35 2004
stop using PyRXP now. It's not an xml parser, and it should eb replaced by PyRXPU ASAP. Then, it would be slow, obviously.#. phil on Tue Dec 21 19:35:43 2004
Ok, so i forget PyRXP forever ... i'm impatient to see PyRXPU compared to others (real?) parsers. The PyRXP's homepage is wrong so ...#. Ian Bicking on Thu Dec 23 09:23:54 2004
I can't speak to the Unicode issues (assuming that's the flaw people are talking about with PyRXP). But I used RXP a while ago, and it seemed fine to me. Honestly, I don't find the tuple-and-list representation to be a problem at all. Certainly a representation using an efficient type would be preferable, but as long as you aren't actually exposing the tuples outside of your domain library, they seem like a reasonable compromise. Maybe with __slots__ (which postdate PyRXP?) the memory efficiency isn't as much of an issue -- though object construction time would still be a concern (assuming that tuples and lists are very fast to create).#. phil on Thu Dec 23 11:42:23 2004
Ian,
Yes the tuple-list-dictionnary representation is fine, i'm ok with that. But then, you have to mix lamba forms, map() calls to extract usefull informations from the tree. I don't use such coding tricks very often (maybe should i ?), so it's not easy.
#. Fredrik on Sun Dec 26 10:31:40 2004
According to my large-file benchmarks (large files, mostly ASCII, lot of elements, few attributes), Gnosis is nearly 10 times slower than RXPU, and uses twice as much memory.
ElementTree 1.2.1 (and later) under Python 2.3 (or later) is as close as you can get with a pure-Python solution, and that's still over 4 times slower and needs 25% more memory. The standard minidom is a little slower than that (but still faster than gnosis), but is extremely memory-hungry.
So don't trust the pundits: RXPU is extremely fast, and very memory-efficient (and RXP is even faster, but more limited).
#. Dj Mixer on Sun Mar 12 20:56:07 2006
ReportLab are proud to present pyRXP version 0.9, the fastest validating XML parser available for Python, and quite possibly anywhere :-).
This is not a full DOM implementation, but we think it will do what 90% of the people want, in 10% of the time. And with validation. Enjoy!
http://www.reportlab.co.uk/svn/public/reportlab/trunk/rl_addons/pyRXP/
#. anon on Sun Dec 19 19:01:43 2004
http://www-106.ibm.com/developerworks/library/x-matters39.html
I'm pretty sure gnosis.xml.objectify is quite close in speed to pyRXP--especially if you compare to the Unicode-enabled pyRXPU that actually parses XML (rather than some XML-like non-standard language: see Uche Ogbuji's comments on this).
At the same time: gnosis.xml.objectify nodes are as Pythonic as you can possibly get. Even more so, IMO, than those in ElementTree, for example.