[Python-Dev] Raising assertions on wrong element types in ElementTree (original) (raw)
Terry Reedy tjreedy at udel.edu
Fri Mar 16 20:49:33 CET 2012
- Previous message: [Python-Dev] Raising assertions on wrong element types in ElementTree
- Next message: [Python-Dev] Raising assertions on wrong element types in ElementTree
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/16/2012 11:33 AM, R. David Murray wrote:
On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky<eliben at gmail.com> 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 PyArgParseTuple 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
- Previous message: [Python-Dev] Raising assertions on wrong element types in ElementTree
- Next message: [Python-Dev] Raising assertions on wrong element types in ElementTree
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]