This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: TreeBuilder.end(tag) differs between cElementTree and ElementTree
Type: behavior Stage: resolved
Components: XML Versions: Python 3.4
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: effbot, eli.bendersky, flox, merrellb, scoder
Priority: normal Keywords:

Created on 2009-10-26 23:32 by merrellb, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg94542 - (view) Author: Brian (merrellb) Date: 2009-10-26 23:32
In the pure python ElementTree, the tag passed to the end() tag is
verified to be closing the last tag opened (self._last).

This cElementTree performs no such validation and closes the last tag
regardless of what tag is passed to the method.

In my mind this raises a couple questions beyond simply fixing this
discrepancy.
1)  Why make this tag mandatory if it has no effect in the cElementTree
version (and in the pure python version is only used to verify the user
isn't confused what tag they are closing)
2)  Could the argument be removed, simply closing the last tag if not
present?
3)  Or could the behavior be changed to actually influence which tag is
closed, allowing one to close all tags out to a specific
outer/encompassing tag (much like close(), closes all tags)?

-brian
msg101210 - (view) Author: Brian (merrellb) Date: 2010-03-17 01:08
What solution did you chose?  While matching cElementTree to the ElementTree
is the simplest solution I think there is some ambiguity as to the what the
preferred behavior as outlined in my original post.

-brian

On Tue, Feb 16, 2010 at 9:41 AM, Florent Xicluna <report@bugs.python.org>wrote:

>
> Changes by Florent Xicluna <laxyf@yahoo.fr>:
>
>
> ----------
> components: +XML -Library (Lib)
> nosy: +flox
> priority:  -> normal
> stage:  -> test needed
> versions: +Python 2.7
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue7214>
> _______________________________________
>
msg113317 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2010-08-08 20:42
The verification of the matching between start and end tag is performed in a debug "assert" statement in the Python version.
This check is ignored if the module is compiled with -O.
It is ignored in the C version, too.

I would suggest to keep the current behavior for both versions.
Fredrik and Stefan are CC'd if they want to comment.
msg113346 - (view) Author: Brian (merrellb) Date: 2010-08-08 22:24
Florent,

Does keeping the current behavior mean no change?  This issue, more
fundamental than this discrepancy, is what is the purpose of the argument to
*end* in the first place?  Why have a required argument that is usually
ignored and when not ignored it used only to verify that one actually knows
the current tag they are ending (ie the argument doesn't actually seem to DO
anything)?

-brian

On Sun, Aug 8, 2010 at 4:42 PM, Florent Xicluna <report@bugs.python.org>wrote:

>
> Florent Xicluna <florent.xicluna@gmail.com> added the comment:
>
> The verification of the matching between start and end tag is performed in
> a debug "assert" statement in the Python version.
> This check is ignored if the module is compiled with -O.
> It is ignored in the C version, too.
>
> I would suggest to keep the current behavior for both versions.
> Fredrik and Stefan are CC'd if they want to comment.
>
> ----------
> nosy: +effbot, scoder
> versions: +Python 3.2 -Python 2.6
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue7214>
> _______________________________________
>
msg166013 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2012-07-21 12:12
does it require action in 3.3, where the C implementation is active by default?
msg166048 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-07-21 17:05
Even if this is a problem at all, it's certainly not something that must be fixed by 3.3
msg189657 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2013-05-20 13:07
TreeBuilder is an interface users can implement. As such, 'tag' is a convenience the user-defined tree builder can use, as in:


class Target(object):
    def start(self, tag, attrib):
        print('i see start', tag)
    def end(self, tag):
        print('i see end', tag)
    def close(self):
        return "DONE"

parser = ET.XMLParser(target=Target())
parser.feed("<TAG>sd</TAG>")

The default TreeBuilder simply needs to build the tree, and it doesn't actually use the tag argument (except for some sanity checking in the Python version). But user code is free to use it.
History
Date User Action Args
2022-04-11 14:56:54adminsetgithub: 51463
2013-05-20 13:07:20eli.benderskysetstatus: open -> closed
resolution: wont fix
messages: + msg189657

stage: test needed -> resolved
2012-07-21 17:05:42eli.benderskysetmessages: + msg166048
versions: + Python 3.4, - Python 3.3
2012-07-21 12:12:28floxsetnosy: + eli.bendersky

versions: + Python 3.3, - Python 2.7, Python 3.2
2012-07-21 12:12:08floxsetmessages: + msg166013
2012-07-21 12:09:19floxsetfiles: - unnamed
2010-08-08 22:24:16merrellbsetfiles: + unnamed

messages: + msg113346
2010-08-08 20:42:53floxsetnosy: + effbot, scoder

messages: + msg113317
versions: + Python 3.2, - Python 2.6
2010-08-08 20:41:14floxsetfiles: - unnamed
2010-03-17 01:08:49merrellbsetfiles: + unnamed

messages: + msg101210
2010-02-16 13:41:11floxsetversions: + Python 2.7
nosy: + flox

priority: normal
components: + XML, - Library (Lib)
stage: test needed
2009-10-27 01:40:40r.david.murraylinkissue7215 superseder
2009-10-26 23:32:28merrellbcreate