Martijn Faassen wrote:
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.
It's just easier to do in objectify, as it has a pretty comprehensive setup for Element class mapping. If you want to be sure to get back exactly the same Element tree after pickling, you can just annotate() an objectify tree before pickling it. Doing the same thing in lxml.etree would require storing some information about the current Element lookup, which may be a lot of information, e.g. for the namespace class setup. That's a parser-local setup, so we can't just use the setup of the default parser either but need a concrete context for the unpickling. lxml.html might be considered having such a context in a similar way lxml.objectify has it, as it comes with its own classes and lookup scheme. Stefan