Stefan wrote:
> Christian, I understand your complaint, but I've actually never seen code in the wild that didn't provide a fallback for the import, usually something like what Serhiy spelled out

My package defusedxml broke with the change. Python's documention recommends my package for parsing XML from untrusted sources. defusedxml 0.7.0rc1 addresses the problem by removing defusedxml.cElementTree in 3.9, too. The fix is going to break other packages, too.

Serhiy wrote:
> xml.etree.cElementTree should be treated in the same way as cStringIO and cPickle -- they where separate modules in the past, but now the acceleration is used by default in io.StringIO and pickle. It looks an oversign that it was not removed in 3.0.

I completely agree with you. It should have been removed with 3.0. But this fact doesn't grant a carte blanche to remove the module without a deprecation phase with a proper deadline.

Stefan wrote:
> So, how do we deal with this? We can't warn about the deprecation without annoying everyone. We can't just remove the empty module without breaking lots of code. We also can't really let the module stick around forever and let people write more code that uselessly imports it.

I prefer annoyance over getting broking by surprise. If the current deprecation warning system doesn't work for us, then we need to come up with a better plan. In the mean time please give users one release head star to adjust their code. I propose that feature shall not be removed in 3.x unless the documentation of 3.(x-1).0 release has explicitly stated the removal of a feature (unless other special circumstances and general consense require it).

* Add deprecation and removal warning for xml.etree.cElementTree to whatsnew/3.9.rst
* Remove xml.etree.cElementTree in 3.10