Related link: http://svn.python.org/view/python/trunk/Lib/xmlcore/etree/
From what I can tell from the flurry of discussion on python-dev, Fred Lundh has formally offered the ElementTree library for inclusion into the Python standard library. The Python-devers appear to have accepted his offer as the link above points to a spot in the Python SVN repository where ElementTree lives in the Python 2.5 branch. The discussion on python-dev appears to be mostly in favor of such inclusion. From this blog entry of Fred’s, it appears that cElementTree has also made it in as well. I didn’t see it in the Lib/xmlcore/etree directory, but I guess it would have to live somewhere else as it is a compiled module.
I find this news quite exciting. I’ve been enjoying ElementTree (and cElementTree) for a little while now, probably over a year. I don’t recall ever wondering, “Why isn’t this thing in the standard library?” although I should have. Practically every new environment that I set up receives the ElementTree libraries as a matter of course. ElementTree is elegant, Pythonic, and easy to handle. cElementTree is all those things, and blazingly fast, as well.
Excellent work, Fred. And if I might add it, congratulations. ElementTree is entirely worthy of inclusion in the standard library.
Great, I've never heard of it.
You should write a little tutorial on it for us avid readers. :D
ElementTree is worthy, yes
ElementTree is indeed entirely worthy of inclusion in the standard library, but is the library worthy of including ElementTree? By which I mean, inclusion in the library means a given module's status is mostly in stasis between Python releases, which perhaps aren't frequent enough.
"Batteries included" is a wonderful idea, but I find more utility in packages that advance (or die -- how can we get rid of the nastiness that is the standard library's *other* XML handling facilities?) separately from the language. In combination with eggs, et al., we have a better mechanism for package distribution anyway.
ElementTree is worthy, yes
You an excellent point. You mention eggs in your post. A cool notion would be to deploy the entire standard library as a group of eggs, much like TurboGears packages dependent projects. If this were the case, libraritized components, such as ElementTree is now, could continue on their own cycle and users could upgrade these individual components between Python releases without fear of damaging or conflicting with the base library. At least, I think this is a cool notion. Inclusion in the standard library should not affect a project. It may, but it need not be so.
This type of packaging would allow for "batteries included" without hindering growth of included modules/packages outside of the standard Python life cycle. Thanks for posting this. It's a perspective worth considering.
ElementTree is worthy, yes
"I find more utility in packages that advance
separately from the language"
Note that ElementTree development hasn't moved over to python-dev. The version shipped with Python will be installed under a separate package name(xml.etree), but will always correspond to an external version (currently 1.2.6/1.0.4).
(if you check the python-dev archives, you'll notice that most of the energy was spent on sorting out how handle this)