[lxml-dev] lxml.objectify.deannotate refuses to clean nil nodes

[Robert Pierce]

Thanks!  That answers my questions.  The apparent asymmetry of handling
nodes was confusing, but the distinction of pytypes vs xsi makes some
sense.  I would naively agree that a seemingly general purpose function like
deannotate should remove everything.  Otherwise, I have to walk the tree
twice: once with deannotate and once to unlink remaining nill types.  Or
recreate my own deannotate().  Not a big deal either way, though.

On Tue, Jun 2, 2009 at 12:24 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:

> Hi,
>
> Holger wrote:
> >> The nil node <Fubar/> is not deannotated as I would expect in the
> >> following
> >> snippet.  I could not find a reference to this behaviour in the archives
> >> or
> >> documentation.  Is this a design feature for which there is a work
> around,
> >> or a bug?  I'm using lxml-2.2-py2.5-linux-i686.
> >
> > Design feature.
>
> I'd be a little more careful with such a big word. ;)
>
>
> > Only py:pytype/xsi:type attributes get removed by deannotate():
> >
> >>>> print etree.__version__
> > 2.1.5
> >>>> help(objectify.deannotate)
> >
> > Help on built-in function deannotate in module lxml.objectify:
> >
> > deannotate(...)
> >     deannotate(element_or_tree, pytype=True, xsi=True)
> >
> >     Recursively de-annotate the elements of an XML tree by removing
> 'pytype'
> >     and/or 'type' attributes.
> >
> >     If the 'pytype' keyword argument is True (the default), 'pytype'
> attributes
> >     will be removed. If the 'xsi' keyword argument is True (the default),
> >     'xsi:type' attributes will be removed.
>
> Yes, so it's even implicitly documented. :)
>
> Anyway, I'm not sure it's always a good idea to leave this special case in
> instead of cleaning everything up. I think if you remove it, you'd get an
> empty string result, which may be surprising - but more surprising than not
> getting it cleaned up? After all, deannotate() means deannotate()...
>
> Stefan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/lxml-dev/attachments/20090602/bf68a118/attachment.htm