| msg90528 - (view) |
Author: Mitchell Model (MLModel) |
Date: 2009-07-15 00:55 |
| The documentation of ElementTree mentions "path" in describing the arguments to certain methods. However, "path" is never defined. I realize that a "path" is (at least a partial implementation of) an XPath, but there's nothing in the documentation to suggest that to someone who is not aware of XPath. I also realize that there is a reference to the external ElementTree documentation, and that ElementTree support for XPath is documented there. I think "path" should at least be clarified with a reference that says something like "As used here the term 'path' refers to ElementTree's support for the XML Path Language (XPath); see see http://effbot.org/zone/element-xpath.htm fordetails" Next, a swarm of nits: The documentation of the Element methods find, findall, and findtext say that their arguments can be a tag name or path. (Using the same wording, which makes it strange that the argument to findtext is called "condition" while the argument to the other two methods are called "match". I'm sure there's something important about this distinction, but I can't figure it out from the documentation. The documentation of the corresponding methods of ElementTree call the arguments "path", rather than "tag" or "condition". The real problem is that these methods are documented with respect to the element(s) "with the given tag". [The "the" is missing from the documentation of ElementTree.find and findall.] The documentation says these methods are the same as calling the corresponding method on getroot(), but whereas the Element methods refer to tag name or path, the ElementTree methods, although they call their arguments "path", only mention tag names. Finally, the ElementTree methods say "path is the [top-level] element to look for", which, it seems to me, is redundant given the first sentence of each of each method's documentation. |
|
|
| msg101868 - (view) |
Author: Jason R. Coombs (jaraco) *  |
Date: 2010-03-28 17:16 |
| I agree. I found the documentation very difficult to understand. The term "top-level" can be confusing. Consider instead something like "search the entire tree". A few other comments about the documentation of findtext: findtext(path[, default]) ... Returns the text content of the first matching element, or the default value no element was found... The first comma (,) following 'element' is unnecessary and in fact incorrect. Also, 'if' is missing. Sentence should read "Returns the text content of the first matching element or the default value if no element was found." findtext(path[, default]) ... Note that if the element has is found, but has no text content, this method returns an empty string. Again, an unnecessary comma exist and there's an extra word. Should read, "Note that if the element is found but has no text content, this method returns an empty string." Note, the wording changes should be made. The other suggestions should be considered soft suggestions and merely my preference. |
|
|
| msg101869 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2010-03-28 17:26 |
| As per PEP 257, “Returns” should become “Return” (it’s a command, not a description). |
|
|
| msg101875 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-03-28 22:14 |
| I think you are incorrect about the comma after element. Without the comma 'the first matching element or the default value' are tightly bound, meaning that if either of those is true, then the default value is returned. That's obviously incorrect, so a human will parse the sentence the way you expect. But I think technically the comma after element turns the sentence into two independent clauses conjoined by 'or', so that either the first matching element is returned, or the default is returned (if no element was found). I think it also reads better rhythmically (you will note that I used a comma in my sentence, as well, even though in that case no technical ambiguity results from leaving it out). The comma in the other sentence I think is optional, and I agree that it reads better without it. |
|
|
| msg102087 - (view) |
Author: Fredrik Lundh (effbot) * |
Date: 2010-04-01 12:02 |
| > As per PEP 257, “Returns” should become “Return” (it’s a command, not a description). Upstream ET uses JavaDoc conventions, where the conventions are designed by technical writers, not hackers. In JavaDoc, descriptions are 3rd person declarative (after all, the documentation describes what the function does, not what you want it to do). http://java.sun.com/j2se/javadoc/writingdoccomments/ The incompatibilities with Python's NIH-standards are unfortunate, but that's the way it is. |
|
|
| msg102088 - (view) |
Author: Fredrik Lundh (effbot) * |
Date: 2010-04-01 12:20 |
| The missing/extra words in the findtext description is just a case of sloppy copy-editing, most likely after a quick reformatting. Not sure why you're spending all this energy arguing about commas, though. |
|
|
| msg113319 - (view) |
Author: Florent Xicluna (flox) * |
Date: 2010-08-08 20:51 |
| Documentation patch accepted, for the "path == XPath" confusion and clarify other points too. http://bugs.python.org/issue6488#msg90528 |
|
|
| msg113345 - (view) |
Author: Florent Xicluna (flox) * |
Date: 2010-08-08 22:23 |
| See also patch attached to #2864 which proposes to add an XPath example to the documentation. |
|
|
| msg156850 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2012-03-26 18:44 |
| New changeset e38f4cf482c7 by Eli Bendersky in branch 'default': Issue #6488: Explain the XPath support of xml.etree.ElementTree, with code http://hg.python.org/cpython/rev/e38f4cf482c7 |
|
|
| msg156852 - (view) |
Author: Eli Bendersky (eli.bendersky) * |
Date: 2012-03-26 18:46 |
| Closing the issue, unless someone wants to back-port this to 3.2/2.7 |
|
|