On Mon, Feb 13, 2012 at 23:16, Nick Coghlan <ncoghlan at gmail.com> wrote: > On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky <eliben at 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.). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120214/cc5a070b/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4