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.

classification
Title: Remove "lightweight" from minidom description
Type: enhancement Stage: resolved
Components: Documentation, XML Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ezio.melotti Nosy List: docs@python, eric.araujo, ezio.melotti, fdrake, flox, loewis, orsenthil, pitrou, python-dev, rhettinger, scoder, tshepang
Priority: normal Keywords: patch

Created on 2011-03-02 19:25 by scoder, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue_11379.1.patch eli.bendersky, 2012-02-29 19:04 review
minidom-desc.diff eric.araujo, 2012-03-02 15:40 review
minidom-desc-2.diff eric.araujo, 2012-03-05 05:21 review
Messages (62)
msg129914 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-03-02 19:25
http://docs.python.org/library/xml.dom.minidom.html

presents MiniDOM as a "Lightweight DOM implementation". The word "lightweight" is easily misunderstood as meaning "efficient" or "memory friendly". MiniDOM is well known to be neither of the two.

The first paragraph then continues:

"""
xml.dom.minidom is a light-weight implementation of the Document Object Model interface. It is intended to be simpler than the full DOM and also significantly smaller.
"""

Again, "smaller" can be misread as "low memory footprint", whereas it is actually supposed to refer to an incomplete DOM API implementation. And "simpler" is also clearly exaggerated when compared to the alternative ElementTree package.

I would like to see this changed and combined with a clear and visible comment that MiniDOM has very high resource profile, e.g.

"""
19.7. xml.dom.minidom — Pure Python DOM implementation

xml.dom.minidom is a pure Python implementation of the Document Object Model interface, as known from other programming languages. It is intended to provide a smaller API than the full DOM.

Note, however, that MiniDOM has a very large memory footprint compared to other Python XML libraries. If you need a fast and memory friendly XML tree implementation with a vastly simpler API, use the xml.etree package instead.
"""
msg129918 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-03-02 21:49
-1. The description is factually correct - minidom *does* have a lower footprint than other Python DOM implementations (such as 4DOM).
msg129934 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-03-03 07:02
Well, I'm not aware of many people who use 4DOM these days, and if that's what it's meant to refer to, maybe that should be made more obvious, because it currently is not at all. Even cDomlette uses only half of the memory according to

http://effbot.org/zone/celementtree.htm

When you say that the description is "factually correct", that does by no means imply that the average reader will understand how it's meant. My point is that almost everyone who reads this will draw the wrong conclusions.

Also, when you say "lower footprint", that does not yet make it "light weight" in any way. It still uses something like ten times as much memory as cElementTree or lxml in Python 2 (and likely much more than even that in Python 3), and still something like 4-5 times as much as plain Python ElementTree. That's a huge difference.

What about this phrasing then:

"""
MiniDOM has a smaller memory footprint than some of the other DOM compliant implementations for Python (such as 4DOM), but uses about 10x more memory than the faster and simpler xml.etree.cElementTree module.
"""
msg129936 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-03-03 08:16
> What about this phrasing then:
> 
> """ MiniDOM has a smaller memory footprint than some of the other DOM
> compliant implementations for Python (such as 4DOM), but uses about
> 10x more memory than the faster and simpler xml.etree.cElementTree
> module. """

But that's not a DOM implementation - so it would be comparing apples
and oranges.
msg129937 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-03-03 08:31
It's the tree based API most python users are parsing XML with, though. So I do not agree that it's comparing apples and oranges, not at all. It's comparing tree based XML libraries, only one of which is worth being called "light weight", and that's not the one that is currently carrying that name.

I think it's worth telling new users what they are committing to when they write code that uses MiniDOM. The documentation should allow them to understand that.
msg129939 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-03-03 08:36
> It's the tree based API most python users are parsing XML with,
> though. So I do not agree that it's comparing apples and oranges, not
> at all. It's comparing tree based XML libraries, only one of which is
> worth being called "light weight", and that's not the one that is
> currently carrying that name.

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.

Notice that the documentation doesn't claim that it is a lightweight
XML library, only that it's a ligthweight DOM implementation. SAX is,
of course, even lighter-weight.
msg129944 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-03-03 09:29
> 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
msg129951 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-03-03 10:58
Agreed with Stefan's concern.
msg148512 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-11-28 18:54
Ok, so, what do we make of this? I proposed improvements to the wording in the documentation, which make it much clearer for users what they are buying into when they start using minidom. I still think that "factually correct" but clearly misleading documentation is not helpful and that it needs fixing. Here is an updated phrasing that I hope we can settle on:

"""
:mod:`xml.dom.minidom` --- Pure Python DOM implementation

[...]

:mod:`xml.dom.minidom` is a pure Python implementation of the Document Object Model interface, as known from other programming languages. It is intended to provide a smaller and simpler API than the full W3C DOM.

Note that MiniDOM has a several times larger memory footprint than :mod:`xml.etree.ElementTree`, the light-weight Python XML library in the standard library. If you do not need a (mostly) compliant W3C DOM implementation, but a fast and memory friendly XML tree implementation with an easy to learn API, use that instead.
"""
msg148558 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-29 13:05
Is memory footprint something important enough to put in the doc?  Ease of use is IMO more important, but then it becomes subjective..
msg148562 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-11-29 13:39
I find a factor of an order of magnitude worth mentioning, because it prevents certain kinds of usages.
msg148565 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-11-29 13:46
Usually we don't talk about performance in the doc, and in my personal experience I didn't notice any major difference between the different implementations (but than again I haven't used them much).
Talking about the other implementations and their advantages/disadvantages is fine, but things like "MiniDOM has a several times larger memory footprint" seems like FUD to me (see also http://docs.python.org/dev/documenting/style.html#affirmative-tone).
msg148566 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2011-11-29 13:49
Removing "Lightweight" and changing the first paragraph to (something like)

:mod:`xml.dom.minidom` is an implementation of the Document Object Model
interface.  The API is slightly simpler than the full W3C DOM, but the
implementation has a significantly higher memory footprint than
:mod:`xml.dom.etree`.

would be entirely reasonable.

(I don't think it's wrong to discuss relative memory footprints in comparison to other modules in the standard library.)
msg148570 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-11-29 14:12
I don't think "FUD" is a suitable term for the rather minidom-friendly wording in my last proposal. Seriously, minidom is widely known for being extremely slow and extremely memory hungry. And that is backed by basically any benchmark that has ever been done on the subject. If 4DOM, which Martin cites, is really worse in terms of performance (I never used it), it must truly be the only existing species of that kind.

Still, here's a cleaned up version of Fred's proposal that I could live with:

"""
:mod:`xml.dom.minidom` --- Pure Python DOM implementation

:mod:`xml.dom.minidom` is an implementation of the Document Object Model interface.  The API is (intentionally) slightly simpler than the full W3C DOM, but the implementation has a significantly higher memory footprint than the XML tree library in :mod:`xml.etree.ElementTree`.
"""
msg148572 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-29 14:14
> I don't think "FUD" is a suitable term for the rather minidom-friendly
> wording in my last proposal. Seriously, minidom is widely known for
> being extremely slow and extremely memory hungry. And that is backed
> by basically any benchmark that has ever been done on the subject.

If it's both slow and memory-hungry, perhaps use the more generic
"performance" instead of "memory footprint"?
msg148578 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-11-29 15:26
> Seriously, minidom is widely known for being extremely slow and 
> extremely memory hungry. And that is backed by basically any benchmark 
> that has ever been done on the subject.

Do you have any link?
My point is that if you say thing like "significantly/several times higher memory footprint than X" you are basically scaring the users away from the module.  If for an average documents it takes, say, 30-50MB of memory, it seems perfectly reasonable to me, even if ElementTree takes 3-5MB.  I would actually consider 100-200MB still ok too, unless I have to parse lot of documents or I'm running low of memory for other reasons.
msg148579 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-29 15:33
> My point is that if you say thing like "significantly/several times
> higher memory footprint than X" you are basically scaring the users
> away from the module.

Only those users who know they'll be processing significantly large
documents.
I don't think "scaring away people" is a good enough reason *not* to
document performance characteristics. For example, we already mention
that string joining is faster than repeated concatenation; I haven't
heard anyone complain that it scared people away from string
concatenation. And while it's true that we shouldn't try to document
performance characteristics *too precisely*, it is still a good thing to
document the most outstanding facts (for examples, C accelerator modules
are clearly superior in performance to pure Python modules; should we
shy away from documenting that, and instead present it as some kind of
neutral choice?).

And, of course, if minidom gets some serious performance attention, the
claims will have to be revisited. But given the amount of attention
minidom gets at all, it sounds rather implausible.

> If for an average documents it takes, say, 30-50MB of memory, it seems
> perfectly reasonable to me, even if ElementTree takes 3-5MB.  I would
> actually consider 100-200MB still ok too

Some use cases would not really like a 100-200MB memory consumption, or
even 50MB. Think a long-running daemon, for instance.
msg148584 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-11-29 16:26
Ezio Melotti, 29.11.2011 16:26:
>> Seriously, minidom is widely known for being extremely slow and
>> extremely memory hungry. And that is backed by basically any benchmark
>> that has ever been done on the subject.
>
> Do you have any link?

I just did a quick Google search for "python minidom benchmark" and found 
these:

http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Python/xml-matters/page2.html

http://effbot.org/zone/celementtree.htm#benchmarks

http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/

Note that all three authors risk being biased, but given how similar the 
results are, I tend to believe them.

Stefan
msg148585 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-29 16:45
> I just did a quick Google search for "python minidom benchmark" and found 
> these:
> 
> http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Python/xml-matters/page2.html
> 
> http://effbot.org/zone/celementtree.htm#benchmarks
> 
> http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/
> 
> Note that all three authors risk being biased, but given how similar the 
> results are, I tend to believe them.

Thanks for the links. The performance gap looks significant enough to be
mentioned, at least generically.
msg148594 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-11-29 19:02
Given that the links were generally somewhat dated and used Py2.x instead of the post-PEP393 Py3.3, here is another little benchmark, comparing the parser performance of minidom to lxml.etree (latest), ElementTree and cElementTree (stdlib) in a recent Py3.3 build (e66b7c62eec0), everything properly optimised for my platform (Linux 64bit). I used os.fork() to start a new process after importing everything and reading the file a couple of times, and before parsing. The memory usage is measured inside of the forked child using the resource module's ru_maxrss value, so it correlates with the growth of CPython's memory heap after parsing, thus giving an estimate of the maximum amount of memory used during parsing and tree building.

Parsing hamlet.xml in English, 274KB:

Memory usage: 7284
xml.etree.ElementTree.parse done in 0.104 seconds
Memory usage: 14240 (+6956)
xml.etree.cElementTree.parse done in 0.022 seconds
Memory usage: 9736 (+2452)
lxml.etree.parse done in 0.014 seconds
Memory usage: 11028 (+3744)
minidom tree read in 0.152 seconds
Memory usage: 30360 (+23076)

Parsing the old testament in English (ot.xml, 3.4MB) into memory:

Memory usage: 20444
xml.etree.ElementTree.parse done in 0.385 seconds
Memory usage: 46088 (+25644)
xml.etree.cElementTree.parse done in 0.056 seconds
Memory usage: 32628 (+12184)
lxml.etree.parse done in 0.041 seconds
Memory usage: 37500 (+17056)
minidom tree read in 0.672 seconds
Memory usage: 110428 (+89984)

A 25MB XML file with Slavic Unicode text content:

Memory usage: 57368
xml.etree.ElementTree.parse done in 3.274 seconds
Memory usage: 223720 (+166352)
xml.etree.cElementTree.parse done in 0.459 seconds
Memory usage: 154012 (+96644)
lxml.etree.parse done in 0.454 seconds
Memory usage: 135720 (+78352)
minidom tree read in 6.193 seconds
Memory usage: 604860 (+547492)

And a contrived 4.5MB XML file with lot more structure than data:

Memory usage: 13308
xml.etree.ElementTree.parse done in 4.178 seconds
Memory usage: 222088 (+208780)
xml.etree.cElementTree.parse done in 0.478 seconds
Memory usage: 103056 (+89748)
lxml.etree.parse done in 0.199 seconds
Memory usage: 101860 (+88552)
minidom tree read in 8.705 seconds
Memory usage: 810964 (+797656)

Things to note: The factor of 5-10 for the memory overhead compared to cET depends heavily on the data. Also, minidom is consistently slower by more than a factor of 10 compared to the fastest parser (apparently the one in libxml2/lxml.etree, both of which surely can't be said to provide less features than the DOM that minidom implements).
msg148598 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-11-29 19:57
Hmm, looks like I messed up the last example. I accidentally left in the formatting whitespace, thus growing the file to 6.2 MB. Removing that, I get this for the (now really) 4.5 MB XML file with lots of structure and very little data:

Memory usage: 11600
xml.etree.ElementTree.parse done in 3.374 seconds
Memory usage: 203420 (+191820)
xml.etree.cElementTree.parse done in 0.192 seconds
Memory usage: 36444 (+24844)
lxml.etree.parse done in 0.131 seconds
Memory usage: 62648 (+51048)
minidom tree read in 5.935 seconds
Memory usage: 527684 (+516084)

It's actually surprising how much of a difference trailing whitespace content makes in minidom (from 2MB on disk to 300MB in memory???), most likely due to the usage of dedicated DOM text nodes in the tree.

PS: I think the "XML/performance" tags on this bug would hint at a separate ticket. This is really meant as a documentation bug.
msg149604 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2011-12-16 09:29
I started a mailing list thread on the same topic:

http://thread.gmane.org/gmane.comp.python.devel/127963

Especially see

http://thread.gmane.org/gmane.comp.python.devel/127963/focus=128162

where I extract a proposal from the discussion. Basically, there should be a note at the top of the xml.dom documentation as follows:

"""
[[Note: The xml.dom.minidom module provides an implementation of the W3C-DOM whose API is similar to that in other programming languages. Users who are unfamiliar with the W3C-DOM interface or who would like to write less code for processing XML files should consider using the xml.etree.ElementTree module instead.]]
"""

I think this should go on the xml.dom.minidom page as well as the xml.dom package page. Hand-wavingly, users who are new to the DOM are more likely to hit the package page first, whereas those who know it already will likely find the MiniDOM page directly.

Note that I'd still encourage the removal of the misleading word "lightweight" until it makes sense to put it back in a meaningful way. I therefore propose the following minimalistic changes to the first paragraph on the minidom page:

"""
xml.dom.minidom is a [-XXX: light-weight] implementation of the Document Object Model interface. It is intended to be simpler than the full DOM and also [+XXX: provide a] significantly smaller [+XXX: API].
"""

Additionally, the documentation on the xml.sax page would benefit from the following paragraph:

"""
[[Note: The xml.sax package provides an implementation of the SAX interface whose API is similar to that in other programming languages. Users who are unfamiliar with the SAX interface or who would like to write less code for efficient stream processing of XML files should consider using the iterparse() function in the xml.etree.ElementTree module instead.]]
"""
msg149611 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-12-16 11:09
> xml.dom.minidom is a [-XXX: light-weight] implementation of the Document Object Model interface.

This is ok.

> It is intended to be simpler than the full DOM and also
> [+XXX: provide a] significantly smaller [+XXX: API].

Doesn't "simpler" here refer to the API already?

Another option is to add somewhere a section like:
"If you have to work with XML, ElementTree is usually the best choice, because it has a simple API and it's efficient [or whatever].  xml.dom.minidom provides a subset of the W3C-DOM API, and xml.sax a SAX interface.", possibly expanding a bit on the differences and showing a minimal example with the 3 different implementations, and then link to it from the other modules' pages.
msg149634 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-12-16 17:59
> "If you have to work with XML, ElementTree is usually the best
> choice, because it has a simple API and it's efficient [or whatever].

I still object such a wording, for many reasons.
msg152836 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-02-08 03:42
IMHO this wording proposed by Stefan:

"""
[[Note: The xml.dom.minidom module provides an implementation of the W3C-DOM whose API is similar to that in other programming languages. Users who are unfamiliar with the W3C-DOM interface or who would like to write less code for processing XML files should consider using the xml.etree.ElementTree module instead.]]
"""

Sounds very reasonable. Perhaps something about a more Pythonic API can also be added there, in addition to "to write less code".

Any objections?
msg152862 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2012-02-08 14:33
On Wed, Feb 08, 2012 at 03:42:16AM +0000, Eli Bendersky wrote:
> Any objections?

None. The explanation sounds reasonable.
msg152866 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-02-08 15:11
+1 to the suggested wording.

-1 to talking about a more pythonic API.

(Want a nit?  s/W3C-DOM/W3C DOM/)
msg152924 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-02-09 04:10
Martin, do you find the wording I quoted (*without* the reference to a more Pythonic API) acceptable?
msg154646 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-02-29 16:37
The wording in msg152836 is fine with me, in particular as it doesn't make any performance claims.
msg154660 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-02-29 19:04
I'm attaching a patch for Doc/library/xml.dom.minidom.rst 

It adds the note as phrased by Stefan, with a tiny wording change to make the first sentence less ambiguous.
msg154673 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-01 05:23
I’m not sure I would use note markup, though (cf. Raymond’s aversion to littering the doc with note and warning boxes).
msg154676 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-01 06:33
>
> I’m not sure I would use note markup, though (cf. Raymond’s aversion to
> littering the doc with note and warning boxes).
>

I also dislike box littering, but this one seems like a really good fit for
a note, since it's completely outside the flow of that documentation page.
msg154677 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2012-03-01 07:04
This is a reasonable case for a note.
msg154735 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-03-02 05:44
New changeset 81e606862a89 by Eli Bendersky in branch '3.2':
Issue #11379: add a note in xml.dom.minidom suggesting to use etree in some cases
http://hg.python.org/cpython/rev/81e606862a89
msg154736 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-03-02 05:46
New changeset ccd16ad37544 by Eli Bendersky in branch '2.7':
Issue #11379: add a note in xml.dom.minidom suggesting to use etree in some cases
http://hg.python.org/cpython/rev/ccd16ad37544
msg154737 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-02 05:47
Committed to 2.7, 3.2 and 3.3

I suppose this issue can be closed now?
msg154756 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2012-03-02 09:54
Thanks Eli.

What about the "Lightweight DOM implementation", though? Following Martin's comment that performance characteristics (like "fast", "memory friendly" or "lightweight") should normally not be documented, I'm still suggesting to replace it with a less easily misinterpreted phrase like "W3C DOM implementation".
msg154759 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-02 10:46
Stefan, frankly I'm not familiar enough with either xml.dom or xml.dom.minidom to have a solid opinion at this point.
msg154760 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-02 10:51
I think I’ve always understood “lightweight” to mean “minimal”.  xml.dom provides minidom, a basic implementation, pulldom, a different implementation, and other libraries such as 4Dom are full-fledged implementations.  So “lightweight” is not a problem to me (but I acknowledge that it might be misleading for other people), especially given that I think that DOM itself is not elegant or lightweight (as in “conceptually small”).
msg154766 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-02 14:51
> I think I’ve always understood “lightweight” to mean “minimal”.

Then how about saying "minimal" instead of "lightweight"?
(also, it seems it really means "incomplete" or "partial", which are of course less positive sounding)
msg154767 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2012-03-02 14:58
"Minimal" sounds good to me, it also matches the name of the module.
msg154772 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-02 15:40
Right, patch for 3.2.  Also edited the module docstring (info taken from the docstring of xml.dom).  BTW I really think we could have avoided some verbosity by adding the recommendation to use xml.etree in the first paragraph of Doc/library/xml.dom.minidom.rst.
msg154773 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-02 15:41
s/Mininal/Minimal/ in the synopsis
msg154774 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2012-03-02 15:55
Yes, I think that's better.
msg154924 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-05 05:21
This alternate version of my patch (a) merges the first two paragraphs to make the intro less redundant and heavy, and (b) reorganizes a bit the list of modules in Doc/library/markup.rst to have xml.etree first and pyexpat (less interesting for most people) at the end.  Tell me if you prefer this version, or if I should commit the first one (possibly with the (b) change).
msg154952 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-03-05 15:26
New changeset d99c0a4b66f3 by Éric Araujo in branch '3.2':
Move xml.etree higher and xml.parsers.expat lower in the markup ToC.
http://hg.python.org/cpython/rev/d99c0a4b66f3
msg154954 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-03-05 15:48
New changeset fc32753feb0a by Éric Araujo in branch '2.7':
Move xml.etree higher and xml.parsers.expat lower in the markup ToC.
http://hg.python.org/cpython/rev/fc32753feb0a
msg155074 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-07 11:37
FYI, note that http://wiki.python.org/moin/MiniDom says this about minidom: “slow and very memory hungry DOM implementation”.

As you have seen, I have applied my ToC order change.  Now in order to commit my s/lightweight/minimal/ change and close this report, can you Eli say if minidom-desc-2 is okay (I’m asking you because this patch touches text you just added, contrary to minidom-desc)?
msg155077 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-03-07 11:44
> FYI, note that http://wiki.python.org/moin/MiniDom says this about  
> minidom: “slow and very memory hungry DOM implementation”.

Thanks for the notice; I have now fixed that wording.
msg155078 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-07 11:53
Éric,

I'm ok with replacing "lightweight" by "minimal", unless others have objections. Regarding the specifics of the minidom-desc-2.diff patch:

   "proficient with the DOM"

I'm not sure "the DOM" is semantically correct. "the W3C-DOM interface" is more precise.

Also, I still think that a note would be more appropriate, but I don't care enough to argue about it :)
msg155081 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2012-03-07 12:27
Oh, right, I missed that part. I also think that a visible note is better. And +1 for "W3C DOM interface".
msg156021 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-16 12:57
Éric, what else would you like to do here?
msg156027 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-16 13:49
I’ll soon have a revised version of my patch to address your feedback.
msg159562 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2012-04-29 02:03
Any news on this?
msg159569 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-04-29 04:18
I’ve been unresponsive of late, sorry, but I’m still here.  Will see if I have time tomorrow.
msg177972 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2012-12-23 10:37
Any news on this?
msg180368 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2013-01-22 07:39
I'm not sure if it's a good idea to keep bikeshedding about this for another two years. Personally, I would prefer having someone with commit rights fix this and be done with it.

Eric's last patch looks ok and parts of it went in already, so it's mostly just the heading that remains to be fixed.
msg180374 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-01-22 10:51
Someone should go ahead and apply this. Éric, perhaps?
msg180409 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2013-01-22 16:22
Sure, feel free to commit this.
msg180434 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-01-22 20:50
New changeset c2ae1ed03853 by Ezio Melotti in branch '2.7':
#11379: rephrase minidom documentation to use the term "minimal" instead of "lightweight".  Patch by Éric Araujo.
http://hg.python.org/cpython/rev/c2ae1ed03853

New changeset b9c0e050c935 by Ezio Melotti in branch '3.2':
#11379: rephrase minidom documentation to use the term "minimal" instead of "lightweight".  Patch by Éric Araujo.
http://hg.python.org/cpython/rev/b9c0e050c935

New changeset 8ff512910338 by Ezio Melotti in branch '3.3':
#11379: merge with 3.2.
http://hg.python.org/cpython/rev/8ff512910338

New changeset 9a0cd5363c2a by Ezio Melotti in branch 'default':
#11379: merge with 3.3.
http://hg.python.org/cpython/rev/9a0cd5363c2a
msg180435 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-22 20:51
Fixed, thanks for the patch!
msg206801 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-12-22 00:57
New changeset 39ea24aaf0e7 by Antoine Pitrou in branch '2.7':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/39ea24aaf0e7

New changeset b63258b6eb4d by Antoine Pitrou in branch '3.3':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/b63258b6eb4d

New changeset d659e7761d59 by Antoine Pitrou in branch 'default':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/d659e7761d59
History
Date User Action Args
2022-04-11 14:57:13adminsetgithub: 55588
2013-12-22 00:57:59python-devsetmessages: + msg206801
2013-01-22 20:51:53ezio.melottisetstatus: open -> closed
type: performance -> enhancement
messages: + msg180435

assignee: docs@python -> ezio.melotti
resolution: fixed
stage: commit review -> resolved
2013-01-22 20:50:22python-devsetmessages: + msg180434
2013-01-22 16:22:04eric.araujosetmessages: + msg180409
2013-01-22 10:51:48pitrousetmessages: + msg180374
stage: needs patch -> commit review
2013-01-22 07:39:34scodersetmessages: + msg180368
versions: + Python 3.4
2012-12-23 10:37:24scodersetmessages: + msg177972
2012-06-08 12:36:44eli.benderskysetnosy: - eli.bendersky
2012-04-29 04:18:59eric.araujosetmessages: + msg159569
2012-04-29 02:03:51ezio.melottisetmessages: + msg159562
2012-03-16 13:49:07eric.araujosetmessages: + msg156027
2012-03-16 12:57:17eli.benderskysetmessages: + msg156021
2012-03-07 12:27:24scodersetmessages: + msg155081
2012-03-07 11:53:49eli.benderskysetmessages: + msg155078
2012-03-07 11:44:37loewissetmessages: + msg155077
2012-03-07 11:37:41eric.araujosetmessages: + msg155074
2012-03-05 15:48:28python-devsetmessages: + msg154954
2012-03-05 15:26:03python-devsetmessages: + msg154952
2012-03-05 05:21:20eric.araujosetfiles: + minidom-desc-2.diff

messages: + msg154924
2012-03-02 15:55:42scodersetmessages: + msg154774
2012-03-02 15:41:34eric.araujosetmessages: + msg154773
2012-03-02 15:40:19eric.araujosetfiles: + minidom-desc.diff

messages: + msg154772
2012-03-02 14:58:51ezio.melottisetmessages: + msg154767
2012-03-02 14:51:54pitrousetmessages: + msg154766
2012-03-02 10:51:30eric.araujosetmessages: + msg154760
2012-03-02 10:46:41eli.benderskysetmessages: + msg154759
2012-03-02 09:54:08scodersetmessages: + msg154756
2012-03-02 05:47:10eli.benderskysetmessages: + msg154737
2012-03-02 05:46:17python-devsetmessages: + msg154736
2012-03-02 05:44:08python-devsetnosy: + python-dev
messages: + msg154735
2012-03-01 07:04:25rhettingersetnosy: + rhettinger
messages: + msg154677
2012-03-01 06:33:50eli.benderskysetmessages: + msg154676
2012-03-01 05:23:19eric.araujosetmessages: + msg154673
2012-02-29 19:04:53eli.benderskysetfiles: + issue_11379.1.patch
keywords: + patch
messages: + msg154660
2012-02-29 16:37:48loewissetmessages: + msg154646
2012-02-29 12:40:32ezio.melottisetstage: needs patch
2012-02-09 04:10:30eli.benderskysetmessages: + msg152924
2012-02-08 15:11:37eric.araujosetmessages: + msg152866
2012-02-08 14:33:02orsenthilsetnosy: + orsenthil
messages: + msg152862
2012-02-08 10:30:08tshepangsetnosy: + tshepang
2012-02-08 03:42:15eli.benderskysetnosy: + eli.bendersky
messages: + msg152836
2011-12-16 17:59:06loewissetmessages: + msg149634
2011-12-16 11:09:20ezio.melottisetmessages: + msg149611
2011-12-16 09:29:16scodersetmessages: + msg149604
2011-11-29 19:57:26scodersetmessages: + msg148598
2011-11-29 19:28:06floxsetcomponents: + XML
2011-11-29 19:27:38floxsetnosy: + flox
type: performance
2011-11-29 19:02:15scodersetmessages: + msg148594
2011-11-29 16:45:17pitrousetmessages: + msg148585
2011-11-29 16:26:23scodersetmessages: + msg148584
2011-11-29 15:33:04pitrousetmessages: + msg148579
2011-11-29 15:26:35ezio.melottisetmessages: + msg148578
2011-11-29 14:14:31pitrousetmessages: + msg148572
2011-11-29 14:12:24scodersetmessages: + msg148570
2011-11-29 13:49:08fdrakesetnosy: + fdrake
messages: + msg148566
2011-11-29 13:46:53ezio.melottisetnosy: + ezio.melotti
messages: + msg148565
2011-11-29 13:39:49scodersetmessages: + msg148562
2011-11-29 13:05:47eric.araujosetnosy: + eric.araujo
messages: + msg148558
2011-11-28 18:54:18scodersetmessages: + msg148512
2011-03-03 10:58:02pitrousetnosy: + pitrou
messages: + msg129951
2011-03-03 09:29:01scodersetnosy: loewis, scoder, docs@python
messages: + msg129944
2011-03-03 08:36:34loewissetnosy: loewis, scoder, docs@python
messages: + msg129939
2011-03-03 08:31:30scodersetnosy: loewis, scoder, docs@python
messages: + msg129937
2011-03-03 08:16:05loewissetnosy: loewis, scoder, docs@python
messages: + msg129936
2011-03-03 07:02:17scodersetnosy: loewis, scoder, docs@python
messages: + msg129934
2011-03-02 21:49:45loewissetnosy: + loewis
messages: + msg129918
2011-03-02 19:25:07scodercreate