Hi Fredrick and Stephan,<div><br></div><div>Thanks a lot for your feedback, I'm happy that you consider that change a bug, and even happier that you already fixed it!</div><div>Looking forward for the lxml 2.2 release...</div>
<div>And thanks for you hard work on ET and lxml! </div><div><br></div><div>Cheers,</div><div><br></div><div>Aloys<br><br><div class="gmail_quote">On Sun, Feb 22, 2009 at 5:09 AM, Stefan Behnel <span dir="ltr"><<a href="mailto:stefan_ml@behnel.de">stefan_ml@behnel.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Fredrik,<br>
<br>
thanks for the clarification.<br>
<div class="Ih2E3d"><br>
Fredrik Lundh wrote:<br>
> Not sure - that you can get None back from findtext when the element<br>
> is there looks like an accidental change when the ElementPath engine<br>
> was rewritten. I think I'll consider that a bug in findtext.<br>
<br>
</div>I thought so, too.<br>
<div class="Ih2E3d"><br>
<br>
> As for distinguishing between <element/> and <element></element><br>
<br>
</div>That's not what I meant, although that actually is the result when you<br>
serialise with or without an empty string value. A parsed empty element<br>
will always have its .text set to None in lxml.etree, regardless of the way<br>
the parser saw it. I rather meant the difference between users setting<br>
<br>
el.text = None<br>
<br>
and<br>
<br>
el.text = ''<br>
<br>
in the code. In the second case, lxml.etree creates a text node with an<br>
empty string in the underlying libxml2 tree. That way, it can return the<br>
expected result on later requests. This is actually compatible with ET,<br>
which (obviously) also remembers what the user set as value. You can think<br>
of the above as an emulation of the ET behaviour, but also as a way to<br>
prevent surprised faces on user side when you see<br>
<br>
el.text = ''<br>
for i in range(10:<br>
el.text += 'xyz'<br>
<br>
fail mysteriously.<br>
<div class="Ih2E3d"><br>
<br>
> the ET specification allows an implementation to use either<br>
> None or an empty string for the text and tail attributes in either<br>
> case to simplify the tree building. However, an application shouldn't<br>
> abuse this - an XML producer should be free to use either form to<br>
> indicate an empty element, and application code should use "truth<br>
> testing" when necessary, when inspecting the text/tail attributes of a<br>
> given element.<br>
<br>
</div>I fully agree.<br>
<div class="Ih2E3d"><br>
<br>
> And I think findtext should be reverted to the 1.2<br>
> behaviour - just add an <or ""> to the suitable place in ElementPath,<br>
> and leave the rest as is.<br>
<br>
</div>That's what I did for lxml 2.2. It just makes findtext() simpler to use.<br>
<font color="#888888"><br>
Stefan<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Aloys Baillet<br>Research & Development - Animal Logic<br>--<br>
</div>