This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients docs@python, loewis, scoder
Date 2011-03-03.09:29:00
SpamBayes Score 3.4298864e-09
Marked as misclassified No
Message-id <1299144541.87.0.619999241678.issue11379@psf.upfronthosting.co.za>
In-reply-to
Content
> If that is a real concern, I'd rather reduce the memory footprint of
> minidom than put actual performance figures into the documentation
> that will likely outdate over time.

Personally, I do not think it's worth putting much work into MiniDOM. I'd rather deprecate it to prevent new code from being written for it, but that's just my personal opinion, and this is the wrong place to discuss that. Given the current performance characteristics, I wouldn't be surprised if there was quite some room for improvements left in the xml.dom package.

If you dislike the "10x", feel free to use "several times". I doubt that MiniDOM will ever get so much closer to cET and lxml to prove that phrasing wrong.


> Notice that the documentation doesn't claim that it is a lightweight
> XML library, only that it's a ligthweight DOM implementation.

I imagine that you are as aware as I am that this nuance is easy to miss, especially for a new user. From my experience, it is very common for users, especially those with a Java-ish background, to confuse the terms "DOM" and "XML tree API/library". Hence my push to change the documentation.


> SAX is, of course, even lighter-weight.

Not so much more light weight than cET's iterparse(), but that's getting OT here.

Stefan
History
Date User Action Args
2011-03-03 09:29:01scodersetrecipients: + scoder, loewis, docs@python
2011-03-03 09:29:01scodersetmessageid: <1299144541.87.0.619999241678.issue11379@psf.upfronthosting.co.za>
2011-03-03 09:29:01scoderlinkissue11379 messages
2011-03-03 09:29:00scodercreate