> 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. > > With the deprecation warning being silent, is there much to lose, though? 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 :-) ?
> 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? Eli
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
