[issue24724] Element.findall documentation misleading
New submission from Eric S: Documentation states: Element.findall() finds only elements with a tag which are direct children of the current element. More accurate to say "direct descendents" as "direct children" implies only one generation below whereas function goes down to all g...children. For-looping findall with inner recursion to rebuild hierarchy as dict, etc. can cause very large tree. -- messages: 247404 nosy: Eric S priority: normal severity: normal status: open title: Element.findall documentation misleading ___ Python tracker <http://bugs.python.org/issue24724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24724] Element.findall documentation misleading
Eric S added the comment: Pointing to XPath and clarifying the example reference are good ideas. For me though, the phrase "direct children" would still lead me to believe that findall() would only give me the first generation right below the element (e.g. only the countries in the example), not grandchildren, greatgrandchildren, etc. That's why I think "direct descendents" or "all descendents" would give a clearer picture. -- ___ Python tracker <http://bugs.python.org/issue24724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24724] Element.findall documentation misleading
Eric S added the comment:
To my preference, the drop-in is verbose and I got a little confused on first
read. The current documentation and example seem mostly OK to me.
If we leave "children" as in "all children of *root*", it doesn't
illuminate the fact that if root had a great-great-grandchild also named
, then it would return that as well.
The only way I can think to simply clarify it is to use "direct descendents" or
"all direct descendents".
Here's how the phrase "direct children" slipped me up when I first read the
docs re:findall():
I thought I could rebuild the XML tree like this:
def rebuild_XML_as_whatever(parent)
for child in parent.findall()
code_that_attaches_child
rebuild_XML_as_whatever(child)
instead I had to do this:
def rebuild_XML_as_whatever(parent)
descendns = parent.findall("./")
for child_n in range(len(descendns)):
child = descendns[child_n]
code_that_attaches_child
rebuild_XML_as_whatever(child)
RE:iterfind() if it fits a new format that's fine but renaming would, of
course, interfere with backwards compatibility.
--
___
Python tracker
<http://bugs.python.org/issue24724>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24724] Element.findall documentation misleading
Eric S added the comment: Code was intended as example, not request for help to correct, but rushed so example was flawed, but still, I tested and you both are right. Must've had other error in code to cause the xml to dict to have every element map to under every node. Debugger also showed findall and list returns with every descendent under every item as well so that influenced my triage. Issue is closed as far as I'm concerned but it sounds like you all found something else here. Sorry for using up your time. Will be more careful and clear if there is a next time. -- ___ Python tracker <http://bugs.python.org/issue24724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1165] Should itertools.count work for arbitrary integers?
Eric S. R-e-mond added the comment: Hi guys. -- assignee: -> esr nosy: +esr __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1165> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1165] Should itertools.count work for arbitrary integers?
Changes by Eric S. R-e-mond: -- severity: minor -> critical __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1165> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1165] Should itertools.count work for arbitrary integers?
Changes by Eric S. R-e-mond: -- keywords: +r-eyyy-mond __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1165> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1165] Should itertools.count work for arbitrary integers?
Changes by Eric S. R-e-mond: -- versions: +3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1165> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1165] Should itertools.count work for arbitrary integers?
Changes by Eric S. R-e-mond: -- type: behavior -> compile error __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1165> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1165] Should itertools.count work for arbitrary integers?
Changes by Eric S. R-e-mond: -- dependencies: +--install-base not honored on win32 type: compile error -> behavior versions: -3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1165> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1165] Should itertools.count work for arbitrary integers?
Changes by Eric S. R-e-mond: -- dependencies: + Elemental Security contribution - pgen2 package __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1165> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1166] NameError when calling malloc
New submission from Eric S. R-e-mond: I tried this code, and it blew up in my face. >>> foo = malloc(4096) NameError: name 'malloc' is not defined Why? -- components: Library (Lib) keywords: r-eyyy-mond messages: 55929 nosy: esr priority: high severity: normal status: open title: NameError when calling malloc type: behavior versions: Python 2.4 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1166> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
