Raising assertions on wrong element types in ElementTree
Locked
Raising assertions on wrong element types in ElementTree
 
|
Hi,
[Terry suggested in http://bugs.python.org/issue13782 to raise this dilemma to python-dev. I concur.] The Element class in ElementTree (http://docs.python.org/py3k/library/xml.etree.elementtree.html) has some methods for adding new children: append, insert and extend. Currently the documentation states that extend raises AssertionError when something that's not an Element is being passed to it, and the others don't mention mention this case. There are a number of problems with this: 1. The behavior of append, insert and extend should be similar in this respect 2. AssertionError is not the customary error in such case - TypeError is much more suitable 3. The C implementation of ElementTree actually raises TypeError in all these methods, by virtue of using PyArg_ParseTuple 4. The Python implementation (at least in 3.2) actually doesn't raise even AssertionError in extend - this was commented out The suggestion for 3.3 (where compatibility between the C and Python implementations gets even more important, since the C one is now being imported by default when available) is to raise TypeError in all 3 methods in the Python implementation, to match the C implementation, and to modify the documentation accordingly. There may appear to be a backwards compatibility here, since the doc of extend mentions raising AssertionError - but as said above, the doc is wrong, so no regressions in the code are be expected. Does that sound reasonable (for 3.3)? Does it make sense to also fix this in 3.2/2.7? Or fix only the documentation? Or not touch them at all? Thanks in advance, Eli _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Raising assertions on wrong element types in ElementTree
|
|
Eli Bendersky, 16.03.2012 08:38:
> The Element class in ElementTree > (http://docs.python.org/py3k/library/xml.etree.elementtree.html) has > some methods for adding new children: append, insert and extend. > Currently the documentation states that extend raises AssertionError > when something that's not an Element is being passed to it, and the > others don't mention mention this case. AssertionError is clearly the wrong thing to raise for user input. > There are a number of problems with this: > > 1. The behavior of append, insert and extend should be similar in this respect > 2. AssertionError is not the customary error in such case - TypeError > is much more suitable > 3. The C implementation of ElementTree actually raises TypeError in > all these methods, by virtue of using PyArg_ParseTuple > 4. The Python implementation (at least in 3.2) actually doesn't raise > even AssertionError in extend - this was commented out > > The suggestion for 3.3 (where compatibility between the C and Python > implementations gets even more important, since the C one is now being > imported by default when available) is to raise TypeError in all 3 > methods in the Python implementation, to match the C implementation, > and to modify the documentation accordingly. +1 Stefan _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Raising assertions on wrong element types in ElementTree
|
|
In reply to this post by Eli Bendersky
On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky <[hidden email]> wrote:
> 1. The behavior of append, insert and extend should be similar in this respect > 2. AssertionError is not the customary error in such case - TypeError > is much more suitable > 3. The C implementation of ElementTree actually raises TypeError in > all these methods, by virtue of using PyArg_ParseTuple > 4. The Python implementation (at least in 3.2) actually doesn't raise > even AssertionError in extend - this was commented out > > The suggestion for 3.3 (where compatibility between the C and Python > implementations gets even more important, since the C one is now being > imported by default when available) is to raise TypeError in all 3 > methods in the Python implementation, to match the C implementation, > and to modify the documentation accordingly. > > There may appear to be a backwards compatibility here, since the doc > of extend mentions raising AssertionError - but as said above, the doc > is wrong, so no regressions in the code are be expected. > > Does that sound reasonable (for 3.3)? Yes. > Does it make sense to also fix this in 3.2/2.7? Or fix only the > documentation? Or not touch them at all? Our usual approach in cases like this is to not change it in the maint releases. Why risk breaking someone's code for no particular benefit? If you want some extra work you could add it as a deprecation warning, I suppose. --David _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Raising assertions on wrong element types in ElementTree
|
|
On 3/16/2012 11:33 AM, R. David Murray wrote:
> On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky<[hidden email]> wrote: >> 1. The behavior of append, insert and extend should be similar in this respect >> 2. AssertionError is not the customary error in such case - TypeError >> is much more suitable >> 3. The C implementation of ElementTree actually raises TypeError in >> all these methods, by virtue of using PyArg_ParseTuple >> 4. The Python implementation (at least in 3.2) actually doesn't raise >> even AssertionError in extend - this was commented out >> >> The suggestion for 3.3 (where compatibility between the C and Python >> implementations gets even more important, since the C one is now being >> imported by default when available) is to raise TypeError in all 3 >> methods in the Python implementation, to match the C implementation, >> and to modify the documentation accordingly. >> >> There may appear to be a backwards compatibility here, since the doc >> of extend mentions raising AssertionError - but as said above, the doc >> is wrong, so no regressions in the code are be expected. >> >> Does that sound reasonable (for 3.3)? > > Yes. Third yes. >> Does it make sense to also fix this in 3.2/2.7? Or fix only the >> documentation? Or not touch them at all? I have no opinion about 2.7 as I have not checked what it currently says and does. In the 3.2 docs, we should remove the erroneous assertion about AssertionError. I think it would be good to also say that CElementTree raises TypeError for erroneous input but ElementTree does not and the the latter mistake is fixed in 3.3. Messy reality makes for messy docs. > Our usual approach in cases like this is to not change it in the maint > releases. Why risk breaking someone's code for no particular benefit? > If you want some extra work you could add it as a deprecation warning, > I suppose. The deprecation warning would be that ignoring the error is deprecated ;-). I think this would be a good idea since it would only appear when someone is checking for how to change their code for 3.3. -- Terry Jan Reedy _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Raising assertions on wrong element types in ElementTree
|
|
On Fri, 16 Mar 2012 15:49:33 -0400, Terry Reedy <[hidden email]> wrote:
> On 3/16/2012 11:33 AM, R. David Murray wrote: > > On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky<[hidden email]> wrote: > >> 1. The behavior of append, insert and extend should be similar in this respect > >> 2. AssertionError is not the customary error in such case - TypeError > >> is much more suitable > >> 3. The C implementation of ElementTree actually raises TypeError in > >> all these methods, by virtue of using PyArg_ParseTuple > >> 4. The Python implementation (at least in 3.2) actually doesn't raise > >> even AssertionError in extend - this was commented out > > > Our usual approach in cases like this is to not change it in the maint > > releases. Why risk breaking someone's code for no particular benefit? > > If you want some extra work you could add it as a deprecation warning, > > I suppose. > > The deprecation warning would be that ignoring the error is deprecated > ;-). I think this would be a good idea since it would only appear when > someone is checking for how to change their code for 3.3. Yes :). But concretely the deprecation warning is that if anyone has code that for some reason *works* with the python version of ElementTree while passing in a non-Element (duck typing?), that will no longer be allowed in 3.3. So it does seem worthwhile to do that. --David _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
«
Return to Python - python-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |