[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Ezio Melotti]

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.
>