| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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:
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.
| Back | FazBrowse Home | New Git URL |
Activity
picnixz commented on Aug 26, 2026
cc @serhiy-storchaka
suhanemathur commented on Aug 27, 2026
Hi @dgelessus ! Thanks for the detailed writeup.
I'd like to take on a subset of these points, specifically the items I've verified directly against the Lib/xml/dom/minidom.py and Lib/xml/dom/minicompat.py source code:
-3: Document Node.childNodes specifically as a NodeList rather than just "a list of nodes."
-6: Add a note clarifying that NodeList is not a subclass of Node (parallel to the existing note for NamedNodeMap).
-7: Correct NodeList.item() docs in xml.dom.rst to clarify that out-of-range indices return None rather than being disallowed/raising.
-8: Clean up stale language in xml.dom.minidom.rst regarding NodeList implementation details to better clarify how childNodes behaves.
-12: Note that Attr nodes only appear in attribute maps and never as child nodes (enforced by HierarchyRequestErr via _child_node_types).
I think the remaining items (#5 regarding nodeName/None, #14/#15 on NamedNodeMap methods, and the broader structural changes) would benefit from further maintainer discussion before working on them. I'm happy to leave those open for @serhiy-storchaka and the team to weigh in on while I can work on the points mentioned above.
picnixz commented on Aug 27, 2026
@suhanemathur Please don't post bare LLM replies that look like "plans". It's not useful to the discussion. First, we need to determine what we want to expose, not just "change the docs". So for now, there is nothing to work on.
serhiy-storchaka commented on Aug 27, 2026
See #155632 which can address some of these points.
dgelessus commented on Aug 27, 2026
Wow, that's some timing :D Thank you for the link, that indeed adds multiple things I was looking for!
I've edited the issue description and marked the items that will be resolved by your PR. The remaining items are still valid, I believe.
pythongh-151943: Document more details of the DOM interfaces
serhiy-storchaka commented on Aug 28, 2026
I added few more fixes in #155632.
#155641 fixes few other documentation points, together with implementation.
dgelessus commented on Aug 31, 2026
Thank you very much, that really helps! Updated the list again.
The few remaining points seem relatively clear to me, so I'll try to submit a PR for those myself (unless someone else wants to do it).
Just to be sure, have I understood correctly how the different combinations of DocumentType.publicId/.systemId map to different kinds of DOCTYPEs?
serhiy-storchaka commented on Sep 1, 2026
Yes, your table is correct for parsed documents, a parser can never produce a public identifier without a system identifier. createDocumentType() does not validate the identifiers, so other combinations can be created programmatically, but they do not make sense in XML.
Neiland85 commented on Sep 16, 2026
Thanks, Serhiy. I’ve incorporated this clarification into #157646, including the distinction between parsed documents and programmatically created DocumentType objects.
The documentation now explicitly describes the PUBLIC, SYSTEM, and no-external-identifier cases, and notes that createDocumentType() does not validate identifier combinations.