[issue20928] xml.etree.ElementInclude does not include nested xincludes
ruffsl <roxfox...@gmail.com> added the comment: > Included file paths should be collected only along an inclusion path and not > across independent subtrees. Yes, well put. > Maybe we should add a "max_depth" parameter to limit the maximum recursion > depth, defaulting to e.g. 5, that users would have to pass in order to say "I > know what I'm doing". Could that be set to false by the user, just in case we don't know beforehand how deep the rabbit hole goes, but we're feeling overly committed to see it through? Not to detract from the ticket, but I'd just like to share to a question related to this topic about the expected behavior of Xinclude [1]. You could also see it as a use case example for the recursive import feature we are currently deciding, of which would help avoid one more non system library to workaround [2]. [1] https://stackoverflow.com/q/48857647/2577586 [2] https://github.com/ComArmor/comarmor/blob/856dd339b090c28e86206d4d6af0fac050618e74/comarmor/__init__.py#L116 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32877] Login to bugs.python.org with Google account NOT working
New submission from ruffsl <roxfox...@gmail.com>: I've been unable to login to bugs.python.org using Google's oauth. After clicking the google oauth logo on the sidebar on bugs.python.org, I am either slowly redirected to a google login page (after about 1 min) to select an account, then after selecting the relevant google account or if I'm only active in it, I'm eventually given a error message after about 2 min of loading time: ``` html An error has occurred An error has occurred A problem was encountered processing your request. The tracker maintainers have been notified of the problem. ``` Other outputs from the browser debug console: ``` Failed to load resource: the server responded with a status of 404 (/tracker/favicon.ico) Failed to load resource: the server responded with a status of 500 (Internal Server Error) ``` This has persisted for about a week now, on multiple machines, bowsers, and ISPs. Presently, the only way I've been able to post this issue at all is due to my first and only login session on one workstation is still active. I suspect this might be a larger issue, only that no one else using google oauth to login has been able to login to file and voise the bug? Related? https://bugs.python.org/issue29544 https://bugs.python.org/issue28887 -- messages: 312374 nosy: ruffsl priority: normal severity: normal status: open title: Login to bugs.python.org with Google account NOT working ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20928] xml.etree.ElementInclude does not include nested xincludes
ruffsl <roxfox...@gmail.com> added the comment: Hello @scoder, Thanks for looking into this. In addition to what I mentioned with lxml's use of the parent xml file's respect dirname when attempting to open the include element's href, do you think it would be possible to (optionally or by default) have the include processor provide the necessary xml:base attributes for compliance with the specification [1][2][3]. I know lxml partially does this, but not for recursive includes beyond a depth of one. Without this, it makes it impossible to track down the subsequent source for deep include paths, i.e. when you'd like to trace from what sequence of includes contributed the element in question. >From looking at the "fixed2", although the added lines 137-143 in >ElementInclude.py appear to prevent infinite recursive includes, but I think >it also prevents valid merging of include trajectories when expanding the tree >of include paths. E.g. what happens if I state the inclusion of the same >source multiple times elsewhere in the same file, or elsewhere in the include >tree that is no way a sub-child of the current parent file. Isn't `already_included` unnecessarily global in scope, when it just need to be relative to the trajectory in the sequence of current branches; only checking a node is not simultaneously a parent and child along a single include trajectory? [1] https://stackoverflow.com/a/22791471/2577586 [2] https://www.w3.org/TR/xmlbase/ [3] http://xerces.apache.org/xerces2-j/faq-xinclude.html#faq-3 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20928] xml.etree.ElementInclude does not include nested xincludes
ruffsl <roxfox...@gmail.com> added the comment: I see it's been a few years, but I would still like to see xml.etree.ElementInclude support nested xincludes, as lxml does. Additionally, I'd like to have the default_loader attempt to open the href with respect to the original xml file's dirname, as again with lxml, as opposed to just assuming its relative to the working directory for the session. Let me know if there are any changes you'd like to see in the latest patch here, and I could incorporate those into a new PR? -- nosy: +ruffsl ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
