[lxml-dev] type of custom objects in XML-tree disappears

Markus Hillebrand himself at markus-hillebrand.de
Wed Jan 23 08:03:11 CET 2008


Thanks for your fast response - with your help I was
able to make my implementation work, but on the design side
I'm not quite satisfied with the solution.

You wrote "You do not have to call set_element_class_lookup()
each time as it sticks with the parser." ... - but thats exactly
what I want to do: I need a tree with objects of different(!)
classes. And I want to put additional data in that objects.

Yes, I read this one: "There is one thing to know up front. Element 
classes must not have a constructor, neither must there be any internal 
state (except for the data stored in the underlying XML tree). Element 
instances are created and garbage collected at need, so there is no way 
to predict when and how often a constructor would be called." on
http://codespeak.net/lxml/element_classes.html

So for me, it seems that lxml seems not to be designed to manage
objects of different classes in an XML tree. With a hack (calling
setElementClassLookup() before each creation of an element) I'm
able to create such tree's and for some testcases it seems to work
fine - despite of these nasty things I reported. But it's not quite
satisficing:

   - it's not free of side-effects, when I change the default
     setElementClassLookup ...
   - I'm afraid to run in garbage collection bugs, like the one I
     reported.

Finally my question: is it possible, that lxml supports that feature
officially? For example by providing an explicit factory call
like etree.createElement(class)?

With  best regards
Markus




More information about the lxml-dev mailing list