You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
py39: remove deprecation note for xml.etree.cElementTree #84246
Same core problem (module removed with insufficient document update), but a different action is needed for 3.8 and 3.9.
When I started testing an application with 3.9 and found one of the dependencies broken because it was relying directly on xml.etree.cElementTree, I had to dig into the history to determine that it was removed intentionally. Updated documentation would have helped.
Thank you for catching this Fred. I am surprised that some code uses xml.etree.cElementTree without falling back to xml.etree.ElementTree. In Python 3 you can just use xml.etree.ElementTree, in Python 2 you have to fallback to the Python implementation because the C implementation was optional.
The Python 2.7 documentation was not clear that xml.etree.cElementTree was optional, so users who didn't dive into the implementation or build process could easily not have known unless someone with a more limited installation used their code.
caje731 commented on Apr 12, 2020
caje731mannequin
Mannequin
More actions
For the record, I submitted a fix to the dependent:
AFAICT from following the discussion, the decision is to hold off on a few deprecations which were causing most of the breakage. However, this does not appear to include xml.etree.cElementTree. Since that has currently been removed in the 3.9 branch, we should indeed fix the docs accordingly.
(Note that previous versions' docs, especially 3.8, should also be updated in this regard, as per the other issue Fred opened about this, bpo-40064.)
(Also, please note that the "master" branch is now for version 3.10; PRs for version 3.9 should be based on the "3.9" branch, and the pull request made for that branch too.)
Doesn't look like it was removed in 3.10. Was this an oversight?
From #80724 (comment) there seems to be no consensus for either removing the module or adding real deprecation warnings. I did end up following the suggestion in #80724 (comment) and got pylint to emit a deprecated-module warning: pylint-dev/pylint#5863.
Activity
freddrake commentedon Mar 25, 2020
Since xml.etree.cElementTree does not exist in Python 3.9, the statement that it's deprecated should be removed from the documentation.
Zheaoli commentedon Mar 26, 2020
I will clean this
This issue looks like the same with https://bugs.python.org/issue40064
freddrake commentedon Mar 26, 2020
Same core problem (module removed with insufficient document update), but a different action is needed for 3.8 and 3.9.
When I started testing an application with 3.9 and found one of the dependencies broken because it was relying directly on xml.etree.cElementTree, I had to dig into the history to determine that it was removed intentionally. Updated documentation would have helped.
I did file an issue on the dependency as well:
boto/botocore#2002
serhiy-storchaka commentedon Mar 26, 2020
Thank you for catching this Fred. I am surprised that some code uses xml.etree.cElementTree without falling back to xml.etree.ElementTree. In Python 3 you can just use xml.etree.ElementTree, in Python 2 you have to fallback to the Python implementation because the C implementation was optional.
serhiy-storchaka commentedon Mar 26, 2020
The common idiom is
try:
import xml.etree.cElementTree as ET
except ImportError:
import xml.etree.ElementTree as ET
freddrake commentedon Mar 26, 2020
The Python 2.7 documentation was not clear that xml.etree.cElementTree was optional, so users who didn't dive into the implementation or build process could easily not have known unless someone with a more limited installation used their code.
caje731 commentedon Apr 12, 2020
For the record, I submitted a fix to the dependent:
boto/botocore#2015
2 remaining items
Zheaoli commentedon May 21, 2020
I'm working on it. I will make a PR today.
idomic commentedon Jun 6, 2020
Tal, is there a decision to this debate or can I just move the dep. warning?
taleinat commentedon Jun 8, 2020
AFAICT from following the discussion, the decision is to hold off on a few deprecations which were causing most of the breakage. However, this does not appear to include xml.etree.cElementTree. Since that has currently been removed in the 3.9 branch, we should indeed fix the docs accordingly.
(Note that previous versions' docs, especially 3.8, should also be updated in this regard, as per the other issue Fred opened about this, bpo-40064.)
taleinat commentedon Jun 8, 2020
(Also, please note that the "master" branch is now for version 3.10; PRs for version 3.9 should be based on the "3.9" branch, and the pull request made for that branch too.)
taleinat commentedon Jun 8, 2020
(My mistake! This should be done from/against the master branch, and then back-ported to 3.9, as usual.)
tiran commentedon Jun 8, 2020
No, please don't change the docs yet. I want to re-introduce the cElementTree and go through a proper deprecation phase.
taleinat commentedon Jun 8, 2020
Ah, thanks for the update Christian, I must have misunderstood your intentions.
So should the deprecation note be removed in the "master" branch for 3.10?
idomic commentedon Jun 20, 2020
Thanks Tal.
Yes, I also got the impression we want to clean this, sorry Christian.
Please let me know how to follow up on this.
iritkatriel commentedon Mar 22, 2022
Doesn't look like it was removed in 3.10. Was this an oversight?
jacobtylerwalls commentedon May 16, 2022
From #80724 (comment) there seems to be no consensus for either removing the module or adding real deprecation warnings. I did end up following the suggestion in #80724 (comment) and got
pylintto emit adeprecated-modulewarning: pylint-dev/pylint#5863.mblahay commentedon Apr 24, 2023
Does this issue require additional research or can it be closed?
jacobtylerwalls commentedon Oct 29, 2024
I think it can be closed. The issue is premised on the removal of cElementTree, but that removal was reverted in #20117.
If there is a plan to resolve the diverging views summarized in #80724 (comment), I think it would be best done on a new issue.