[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 75268a773455 by Eli Bendersky in branch 'default': Issue #13782: streamline argument type-checking in ET.Element http://hg.python.org/cpython/rev/75268a773455 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Eli Bendersky eli...@gmail.com added the comment: Closing the issue. 3.3 was fixed, and there was no concensus regarding 2.7/3.2 in the list, so status-quo as usual. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Changes by Eli Bendersky eli...@gmail.com: -- stage: test needed - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Eli Bendersky eli...@gmail.com added the comment: Attaching a patch that sets the record straight in 3.3 - the 3 methods will raise TypeError, in both C and Python implementations. Also adds a test that verifies this, and updating the documentation. Note that in the C implementation extend wasn't actually type-checking its argument as well, so I added it for consistency. I don't believe this will be a performance problem. On the contrary, there are some type checking calls inside the implementation that can probably be removed now that we make sure only subclasses of Element get in as children. I'll look into this later. -- keywords: +patch Added file: http://bugs.python.org/file24897/issue13782.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Changes by Eli Bendersky eli...@gmail.com: Removed file: http://bugs.python.org/file24897/issue13782.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Changes by Eli Bendersky eli...@gmail.com: Added file: http://bugs.python.org/file24898/issue13782.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Eli Bendersky eli...@gmail.com added the comment: Link to related python-dev discussion: http://mail.python.org/pipermail/python-dev/2012-March/117715.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Florent Xicluna florent.xicl...@gmail.com added the comment: Actuallly, the assertions were commented in the upstream repository. https://bitbucket.org/effbot/et-2009-provolone/src/9e9e7f2710aa/elementtree/CHANGES#cl-46 (1.3a6 released) - Removed most assert statements from the Element and ElementTree code. It looks more useful to me to have a consistent behavior between C and Python version. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Eli Bendersky eli...@gmail.com added the comment: It looks more useful to me to have a consistent behavior between C and Python version. I agree, especially is we now consider to expose the C API by default, leaving the Python API as a fallback. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Terry J. Reedy tjre...@udel.edu added the comment: Option 1 is to fix the regression in the 2.7/3.2 Python versions and change the C version to conform to the doc and older Python versions., even though it is the wrong error, and even though Python asserts disappear with -O (which is why it is the wrong error). Option 2 is to leave cET alone with the correct error and fix 2.7/3.2 and the docs to conform. Option 3 is to leave cET alone and leave 2.7/3.2 alone as done deals, even if bad. Change 3.3 Python and docs to TypeError. We would need a version-changed note, but perhaps should mention the 3.2 behavior so as to not give a mis-impression. I think I favor 3, but after presenting the trilemma on pydev. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Eli Bendersky eli...@gmail.com added the comment: Terry, I agree with 3. The regression here is insignificant enough in my view to warrant mucking with already released versions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Changes by Eli Bendersky eli...@gmail.com: -- nosy: +eli.bendersky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Terry J. Reedy tjre...@udel.edu added the comment: Confirmed with on 3.2.2 Win7 for all three methods. Docs say .append should raise AssertionError (see below). However, that is unusual and TypeError is normal practice. I am not sure what to do. Our docs say: ''' append(subelement) Adds the element subelement to the end of this elements internal list of subelements. extend(subelements) Appends subelements from a sequence object with zero or more elements. Raises AssertionError if a subelement is not a valid object. insert(index, element) Inserts a subelement at the given position in this element. ''' This implies to me that append and insert should do the same. In fact, the current code has the assertion checks but they are commented out in all methods. From http://effbot.org/zone/pythondoc-elementtree-ElementTree.htm append ... Raises AssertionError: If a sequence member is not a valid object. Ditto for .insert Florent: why are all the assertion checks commented out in Changeset: 59511 (831e30c0fd73) Issue #6472: The xml.etree package is updated to ElementTree 1.3. (March 2010) Is the change in Fredrik's code, in spite of his docs? -- nosy: +effbot, flox, terry.reedy stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
New submission from John Machin sjmac...@lexicon.net:
import xml.etree.ElementTree as et
node = et.Element('x')
node.append(not_an_Element_instance)
2.7 and 3.2 produce no complaint at all.
2.6 and 3.1 produce an AssertionError.
However cElementTree in all 4 versions produces a TypeError.
Please fix 2.7 and 3.2 ElementTree to produce a TypeError.
--
messages: 151210
nosy: sjmachin
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree: Element.append doesn't type-check its argument
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13782
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Changes by Santoso Wijaya santoso.wij...@gmail.com: -- components: +Library (Lib), XML nosy: +santa4nt versions: +Python 3.3 -Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument
Santoso Wijaya santoso.wij...@gmail.com added the comment: This does not only affect `append`, but also, `insert`, `extend`, etc. In fact, the list-like operations on Element are merely forwarded to its `_children` (a list) field. Should we really type check these methods' arguments each? Doesn't strike as Pythonic to me... OTOH, in cElementTree, by virtue of C-API's tuple unpacking convention, the argument's type is always strictly checked prior to accessing the children list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
