On 16/02/2012 19.55, Antoine Pitrou wrote:
On Thu, 16 Feb 2012 19:32:24 +0200
Ezio Melotti<ezio.melo...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
