[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Nick Coghlan]

On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky <eliben at gmail.com> wrote:
> With the deprecation warning being silent, is there much to lose, though?

Yes, it creates problems for anyone that deliberately converts all
warnings to errors when running their test suites. This forces them to
spend time switching over to a Python version dependent import of
either cElementTree or ElementTree that could have been spent doing
something actually productive instead of mere busywork.

And, of course, even people that *don't* convert warnings to errors
when running tests will have to make the same switch when the module
is eventually removed.

> Cleanups help lower the clutter and mental burden on maintainers in the long
> run. If nothing is ever cleaned up don't we end up with PHP :-) ?

It's a balancing act, sure. But when the maintenance burden for us is
low and the cost to third parties clear, documented deprecation for
eventual removal in the next release series is the better choice.

>> Programmatic deprecation is a significant imposition on third party
>> developers and should really be reserved for APIs that actively
>> encourage writing broken code (e.g. contextlib.nested) or are
>> seriously problematic for python-dev to maintain. For cleanup stuff,
>> documented deprecation is sufficient.
>
> A quick search of the sources for DeprecationWarning show that it's being
> used much more liberally than solely for stuff that encourages writing
> broken code. Has there been a recent policy change with regards to what's
> considered deprecated?

It's always been judged on a case-by-case basis, but yes, there's been
a deliberate push in favour of purely documented deprecations in
recent years (initially mostly from Raymond Hettinger, more recently
from me as well as I came to appreciate the merit of Raymond's point
of view). It mainly started with the decision to leave optparse alone
(aside from a deprecation note in the docs) even after argparse was
added to the standard library.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia