[lxml-dev] annotate, pyannotate, xsiannotate

Stefan Behnel stefan_ml at behnel.de
Wed Sep 12 20:19:49 CEST 2007


jholg at gmx.de wrote:
>> I propose renaming the existing annotate() function to pyannotate() and
>> adding a public interface annotate() to the internal _annotate(), so you can
>> xsi-typify and py-typify in one step.

Sure, that's fine.


>> I also think it would be better to change the defaults of the "ignore_old"
>> keyword args of the annotation functions to False

Definitely ok for the new ones. Maybe for annotate() also, I'm not sure yet.


> Attached is patch that does just that, with tests.
> 
> I quirked the defaults for the new annotate() function that can now
> py:pytype and xsi:type-annotate in one step so that it behaves just like
> the former annotate() (at least it passes all the existing unittests which
> I did not alter) The new pyannotate() and xsiannotate() use different
> defaults, as suggested.

I still have to look through the patch a bit more, but I generally like the
intention, except:


> There's an additional keyword arg keep_tree that lets you preserve existing TREE attribute values, if switched on.

No way. :)

It doesn't match the existing "ignore_*" parameters and the default is to
/remove/ the tree annotation when what we want is to /create/ annotations.

Taking one step back: what was the reason again why we started using TREE
annotation at all? I mean, it doesn't have any advantage and it currently
looks like it's getting in the way. Is there a reason that should keep us from
just dropping it? completely? (minus backwards compatibility?)

I mean, honestly, it's not used and it's even faster to check for children
than it is to look up the attribute...

Stefan



More information about the lxml-dev mailing list