I combed through the mailing list archives and confirmed that I never got a response to this inquiry. To re-cap, I'm looking for a way to pass in a reference to user data when invoking the XSLT object to transform a tree, and to have that user data object accessible to the resolver callbacks. Is there support somewhere for this that I just haven't find? If not, how hard would it be to implement this? I'm willing to contribute toward such an effort. Thanks! Bob On Wed, Mar 22, 2017 at 8:32 AM, Bob Kline <bkline@rksystems.com> wrote:
The subject of my post was misleading. I'm aware that I could use a threading.local object to isolate thread-specific data. What I'm really hoping for is stack-based data which carries information about the individual XSL/T filtering call. The way Sablotron (R.I.P.) allowed an opaque pointer to a structure of user data to be passed into SablotRegHandler(). I could implement my own stack (so that if a callback ended up invoking another filtering operation it wouldn't obliterate the data specific to the original XSL/T job), but it would be cleaner if lxml provides a way to register user data for the filtering call.
Thanks, Bob
-- Bob Kline http://www.rksystems.com mailto:bkline@rksystems.com