[Python-Dev] Raising assertions on wrong element types in ElementTree (original) (raw)
R. David Murray rdmurray at bitdance.com
Fri Mar 16 21:02:01 CET 2012
- Previous message: [Python-Dev] Raising assertions on wrong element types in ElementTree
- Next message: [Python-Dev] Summary of Python tracker Issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 16 Mar 2012 15:49:33 -0400, Terry Reedy <tjreedy at udel.edu> wrote:
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
> 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
- Previous message: [Python-Dev] Raising assertions on wrong element types in ElementTree
- Next message: [Python-Dev] Summary of Python tracker Issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]