Hello Stefan, Wednesday, May 10, 2006, 7:49:59 AM, you wrote:
Stefan Behnel wrote:
Steve Howe wrote:
simply calling unicode() on XML nodes and ElementTrees. It behaves just like tostring(), but always returns Python unicode strings:
> el = etree.Element("test") > unicode(el) u'<test/>' As usual: any comments appreciated. Shouldn't this be implemented as etree.tounicode() or something like
Wednesday, May 10, 2006, 6:39:29 AM, you wrote: that instead ? This will be more intuitive since there is the tostring() method.
I think there's one good argument that fits independent of the question which is more intuitive: extensibility. The unicode() function is fixed and does not allow us to extend the call parameters to support things like "prettyprint=True" keyword arguments.
And that's already a difference to "_XSLTResultTree.__unicode__": that API will never need to be extended as it is configured through xsl:output.
Ok, so I'm convinced that our home-grown tounicode() is better. I'll fix it on the trunk. Well thought. I think it would not hurt, however, if unicode() calls .tounicode() with default params, *if* str() behaves the same way. in fact, there is no point in printing <Element a at 8413144> at all - is there ? That would bring the best of both worlds, the extensibility/compatibility of .tostr()/.unicode(), and the intuitive str()/unicode() call.
Besides, repr(root) will be printing the same as str(root) does today, in case someone really wants that... -- Best regards, Steve mailto:howe@carcass.dhs.org