Stefan Behnel wrote: [snip]
I think it makes a little less sense in lxml.etree where you'd have to keep some more state about the Element classes used inside the tree. I'm not sure how valuable this is in lxml.html.
I'd love it if I could somehow store lxml trees in the ZODB, and that'd need pickle support. Whether it could be made to be efficient I don't know - you'd not want the whole tree to be pickled as a whole in case of large trees, but some form of partitioning scheme into separate pickles. You're right that custom-element binding would be nice in this case, and that means the pickle can't simply be the XML content unless it's somehow annotated first. Anyway, this is a rather out there use case. I am just intrigued to learn that objectify elements can be pickled. Regards, Martijn