[Python-Dev] folding cElementTree behind ElementTree in 3.3 (original) (raw)

Ezio Melotti ezio.melotti at gmail.com
Fri Feb 17 23:56:17 CET 2012


On 18/02/2012 0.04, Nick Coghlan wrote:

On Fri, Feb 17, 2012 at 4:29 AM, Ezio Melotti<ezio.melotti at gmail.com> wrote:

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. Not really - as soon as we programmatically deprecate something, it means anyone with a strict warnings policy (or with customers that have such a policy) has to update their code now. (Previously it was even worse than that, which is why deprecation warnings are no longer displayed by default).

The ones with a strict warning policy should be ready to deal with this situation.

A possible solution (that I already proposed a while ago) would be to reuse the 2to3 framework to provide fixers that could be used for these "mechanical" updates between 3.x releases. For example I wrote a 2to3 fixer to replace all the deprecate unittest methods (fail*, some assert*) with the correct ones, but this can't be used to fix them while moving from 3.1 to 3.2.

For things that we have no intention of deprecating in 3.x, but will likely ditch in a hypothetical future Python 4000, we'll almost certainly do exactly what we did with Pyk: later in the 3.x series, add a "-4" command line switch and a sys.py4kwarning flag to trigger conditional deprecation warnings.

I think Guido mentioned somewhere that this hypothetical Python 4000 will most likely be backward compatible, so we would still need a regular deprecation period.

So, assuming things continue as they have for the first couple of decades of Python's existence, we can probably start worrying about it some time around 2020 :)

What bothers me most is that a valid mechanism to warn users who cares about things that will be removed is being hindered in several ways.
DeprecationWarnings were first silenced (and this is fine as long as the developers are educated to enable warnings while testing), now discouraged (because people are still able to make them visible and also to turn them into errors), and on the tracker there's even a discussion about making the deprecation notes in the doc less visible (because the red boxes are too "scary").

See also http://mail.python.org/pipermail/python-dev/2011-October/114199.html

Best Regards, Ezio Melotti

Cheers, Nick.



More information about the Python-Dev mailing list