Raising assertions on wrong element types in ElementTree

[Eli Bendersky]

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

[Stefan Behnel-3]

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

[R. David Murray]

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

[Terry Reedy]

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

[R. David Murray]

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