Re: [lxml] thread-specific data for xslt callbacks

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