On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky <eliben@gmail.com> wrote:
> An open question remains on whether to deprecate cElementTree, now that this
> change is in place.
>
> Currently in 3.3 the whole cElementTree module is:
>
>   # Deprecated alias for xml.etree.ElementTree
>
>   from xml.etree.ElementTree import *
>
> Would it be alright to issue a DeprecationWarning if this module is
> imported? Then hopefully a couple of releases after 3.3 we can just dump it.

What do we really gain by dumping it, though? Just add a CPython
specific test that ensures:

    for key, value in xml.etree.ElementTree.__dict__.items():
        self.assertIs(getattr(xml.etree.cElementTree, key), value)

and then ignore it for the next decade or so.

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.

Something that might be worth doing (although it would likely scare
the peanut gallery) is to create a PEP 4000 to record the various
cleanup tasks (like dropping cElementTree) that are being deliberately
excluded from the 3.x series.

I honestly think a PEP 4000 is a good idea simply to document stuff that we are allowing to exist in Python 3 but don't think people should necessarily be using in order to follow best practices (e.g. this, ditching optparse, no more % string formatting, etc.).
">

(original) (raw)



On Mon, Feb 13, 2012 at 23:16, Nick Coghlan <ncoghlan@gmail.com> wrote:

On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky <eliben@gmail.com> wrote:
> An open question remains on whether to deprecate cElementTree, now that this
> change is in place.
>
> Currently in 3.3 the whole cElementTree module is:
>
> # Deprecated alias for xml.etree.ElementTree
>
> from xml.etree.ElementTree import \*
>
> Would it be alright to issue a DeprecationWarning if this module is
> imported? Then hopefully a couple of releases after 3.3 we can just dump it.

What do we really gain by dumping it, though? Just add a CPython
specific test that ensures:

for key, value in xml.etree.ElementTree.\_\_dict\_\_.items():
self.assertIs(getattr(xml.etree.cElementTree, key), value)

and then ignore it for the next decade or so.

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.

Something that might be worth doing (although it would likely scare
the peanut gallery) is to create a PEP 4000 to record the various
cleanup tasks (like dropping cElementTree) that are being deliberately
excluded from the 3.x series.

I honestly think a PEP 4000 is a good idea simply to document stuff that we are allowing to exist in Python 3 but don't think people should necessarily be using in order to follow best practices (e.g. this, ditching optparse, no more % string formatting, etc.).