[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Ezio Melotti]

On 16/02/2012 19.55, Antoine Pitrou wrote:
> On Thu, 16 Feb 2012 19:32:24 +0200
> Ezio Melotti<ezio.melotti at gmail.com>  wrote:
>> If I'm writing code that imports cElementTree on 3.3+, and I explicitly
>> turn on DeprecationWarnings (that would otherwise be silenced) to check
>> if I'm doing something wrong, I would like Python to tell me "You don't
>> need to import that anymore, just use ElementTree.".
>> If I'm also converting all the warnings to errors, it's probably because
>> I really want my code to do the right thing and spending 1 minute to
>> add/change two line of code to fix this won't probably bother me too much.
> But then you're going from a cumbersome situation (where you have to
> import cElementTree and then fallback on regular ElementTree) to an
> even more cumbersome one (where you have to first check the Python
> version, then conditionally import cElementTree, then fallback on
> regular ElementTree).

This is true if you need to support Python <=3.2, but on the long run 
this won't be needed anymore and a plain "import ElementTree" will be 
enough.

>
>> When the module is eventually removed and you didn't warn them in
>> advance, the situation is going to turn much worse, because their code
>> will suddenly stop working once they upgrade to the newer version.
> Why would we remove the module? It seems "supporting" it should be
> mostly trivial (it's an alias).

I'm assuming that eventually the module will be removed (maybe for 
Python 4?), and I don't expect nor want to seen it removed in the near 
future.
If something gets removed it should be deprecated first, and it's 
usually better to deprecate it sooner so that the developers have more 
time to update their code.
As I proposed on the tracker though, we could even delay the deprecation 
to 3.4 (by that time they might not need to support 3.2 anymore).

>
>> I would watch this from the opposite point of view.  Why should the
>> other Python implementation have a to keep around a dummy module due to
>> a CPython implementation detail?
> I don't know, but they already have this module, and it certainly costs
> them nothing to keep it.

There will also be a cost if people keep importing cElementTree and fall 
back on ElementTree on failure even when this won't be necessary 
anymore.  This also means that more people will have to fix their code 
if/when the module will be removed if they kept using cElementTree.  
They can also find cElementTree in old code/tutorial and figure out that 
it's better to use the C one because is faster and keep doing so because 
the only warning that would stop them is hidden in the doc.

I think the problem with the DeprecationWarnings being too noisy was 
fixed by silencing them; if they are still too noisy then we need a 
better mechanism to warn people who care (and going to check the doc 
every once in a while to see if some new doc warning has been added 
doesn't strike me as a valid solution).

Best Regards,
Ezio Melotti