`xml.dom` docs are missing important information necessary for usage
@serhiy-storchaka arbeitet bereits daran.
Seit 27.8.2026.
- Vorherrschende Sprache
- Python
- Sterne
- 77.2k
- Forks
- 35.9k
- PR-Merge-Kennzahlen
- PR-Kennzahlen ausstehend
Beschreibung
Documentation
I recently tried to use xml.dom/xml.dom.minidom for the first time, as someone who has moderate experience with other Python XML libraries (xml.etree.ElementTree, lxml, BeautifulSoup), but almost no prior experience with DOM APIs in any programming language. I found that the Python docs for xml.dom and xml.dom.minidom are missing important bits of information, so I had trouble making sense of these APIs, until I started looking at the source code, typeshed stubs, and external documentation.
Some (but not all) of the missing information can be found in the W3C DOM spec. It's not clear to me if readers of the xml.dom docs are expected to know the DOM spec already. If so, it would be good to clearly say so at the start of the docs, and to link the spec more prominently than just in the "See also" box.
The specific missing/unclear/confusing info I noticed:
- The docs for
getDOMImplementationmention "well-known" implementation names, but these "well-known" names don't seem to be documented. I can only find a list in thexml.dom.domregsource code. - There is no explanation of the possible children of each node type. For some types, there is a short mention that they have no children, but the rest is unexplained. I had to refer to the DOM spec and experiment interactively to properly understand which node types can appear where in the tree.
-
Node.childNodesis documented only as "A list of nodes" when it's specifically aNodeListaccording to the DOM spec. - The docs for
Node.nodeNameandNode.nodeValuesay that they correspond to other, type-specific attributes, but don't show the exact mappings for each node type. They do explicitly refer to the DOM spec, which is good, but it would be better to provide this information inline (or at least link to the right subsection of the spec). - The docs say that
Node.nodeNamecan beNone, but if I'm reading the DOM spec right,nodeNameis non-null for every possible node type. This might be an error in the docs. - It would be good to explicitly point out that
NodeListisn't a subclass ofNode, the same way this is pointed out forNamedNodeMap. - The
NodeList.itemdocs make it sound like the list can containNoneelements and out-of-range indices are disallowed. In reality, out-of-range indices are allowed and result inNone(and apparently that this is the only case whereNoneis returned?). - The
xml.dom.minidomdocs say "NodeListobjects are implemented using Python’s built-in list type.". This isn't useful information for a user of minidom, and makes it sound like minidom is using plainlistinstead ofNodeList, which isn't the case. -
DocumentType.publicIdandDocumentType.systemIdcan beNone, but it's not explained when that happens, in which combination, and what it means. I assume theNone-ness of these attributes indicates whether the doctype is aPUBLICor aSYSTEMone, as there's no other API that indicates this. -
DocumentType.nameis documented as "The name of the root element as given in theDOCTYPEdeclaration, if present." (emphasis mine). Can aDocumentTypeever have no name? The DOM spec doesn't say so, and in the XML syntax, the name is a required part of a<!DOCTYPE ...>. -
DocumentType.entitiesandDocumentType.notationsare documented, but theEntityandNotationnode types they contain are undocumented, except for their node type constants. - It would be good to point out that
Attrnodes are never children of anything and only appear inattributesmaps. -
Attr.localNameandAttr.prefixare documented underAttr, even though they're seemingly identical to the baseNodeattributes of the same names. -
NamedNodeMap's...NamedItem[NS]methods (from the DOM spec) are not documented, even though minidom implements them. - The
NamedNodeMapdocs mention "experimental methods that give this class more mapping behavior", but don't document them. I could only find these methods in the minidom source code and typeshed stubs. They also differ somewat from the normal PythonMappingmethods, so it's not enough to documentNamedNodeMapas a Python mapping.- minidom has two classes implementing the
NamedNodeMapinterface -NamedNodeMapandReadOnlySequentialNamedNodeMap- and only the former implements the mapping-like methods. It's not documented when minidom uses which implementation (this is again only visible in the source code and stubs), so it's impossible to use the mapping-like methods reliably.
- minidom has two classes implementing the
-
CommentandTexthave a common base interfaceCharacterData, which is completely undocumented. (Duplicates gh-155631.) -
TextandCDATASectionare documented together, but it's never mentioned thatCDATASectioninherits fromText. - The documentation pages for both
xml.domandxml.dom.minidomhave sections at the end explaining how the DOM spec and IDL are mapped to Python. These seem to be mostly redundant with each other, so it's unclear which bits are part of the "Python DOM API" and which are implementation details of minidom.
Sorry for the long list! I hope this is useful feedback.
I might be able to start fixing some of these issues, but I'm not sure how useful that would be, because I'm not confident that I've understood it all correctly yet.
Linked PRs
- gh-157646
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Bewertung
Dieses Issue wurde noch nicht bewertet.