This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients eli.bendersky, martin.panter, rhettinger, scoder
Date 2015-05-26.06:43:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432622635.16.0.669981065753.issue24287@psf.upfronthosting.co.za>
In-reply-to
Content
FTR, lxml's Element class has addnext() and addprevious() methods which are commonly used for this purpose. But ET can't adopt those due to its different tree model.

I second Martin's comment that ET.append() is a misleading name. It suggests adding stuff to the end, whereas things are actually being inserted before the root element here.

I do agree, however, that this is a helpful feature and that the ElementTree class is a good place to expose it. I propose to provide a "prolog" (that's the spec's spelling) property holding a list that users can fill and modify any way they wish. The serialiser would then validate that all content is proper XML prologue content, and would serialise it in order.

My guess is that lxml would eventually use a MutableSequence here that maps changes directly to the underlying tree (and would thus validate them during modification), but ET can be more lenient, just like it allows arbitrary objects in the text and tail properties which only the serialiser rejects.

Note that newlines can easily be generated on user side by setting the tail of a PI/Comment to "\n". (The serialiser must also validate that the tail text is only allowed whitespace.)

For reference:

http://www.w3.org/TR/REC-xml/#sec-prolog-dtd
History
Date User Action Args
2015-05-26 06:43:55scodersetrecipients: + scoder, rhettinger, eli.bendersky, martin.panter
2015-05-26 06:43:55scodersetmessageid: <1432622635.16.0.669981065753.issue24287@psf.upfronthosting.co.za>
2015-05-26 06:43:55scoderlinkissue24287 messages
2015-05-26 06:43:54scodercreate