Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #17161 > unrolled thread

Re: Fixing the XML batteries

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Fixing the XML batteries Serhiy Storchaka <storchaka@gmail.com> - 2011-12-13 20:57 +0200

#17161 — Re: Fixing the XML batteries

13.12.11 16:59, Stefan Behnel написав(ла):
> It matches my opinion though.

I would be glad to divide your intentions, however ElementTree looks 
less documented than minidom, and is not full replacement. For example, 
I haven't found how to get XML encoding. Also, at use of ElementTree 
instead of minidom the suffix "ns0:" is added to each element. I do not 
see how to _create_ a new element and to write it with <?xml ...?> header.

And DOM interface is more habitual for those who works with some other 
languages.

> Yes, that's what C14N is there for, typically used for cryptography,
> hashing, etc. However, MiniDOM doesn't implement that standard, so
> you're on your own here.

MiniDOM quite suited me earlier in this respect. I will pass to C14N as 
soon as I will be can.

> The ET module is actually quite short (<1700 lines), so you can just
> copy the Py2.7 version into your sources and optionally import it on
> older Python releases. Since you only seem to depend on the serialiser
> (which is worth using anyway because it is much faster in the Py2.7
> version), older platform versions of cET should also work just fine with
> that module copy, so you can basically just import everything from
> xml.etree.cElementTree and use the ElementTree class and the tostring()
> function from your own local version if the platform version is too old.
>
> Note that ET is also still available as a separately installable
> package, may or may not be simpler to use for you.

I thank, it is too bulky for my small scripts (which I have decided to 
update from Python 2.3 or 2.4 to modern Python 3 and 2.6+). I will 
better postpone high-grade migration for half-year or year while the 
Python 2.7 and 3.2 won't appear in stable versions of popular distributives.

I thank you for ET, it really is more convenient at some applications 
(especially at work with the text in elements).

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web