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.


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.


Bob Kline