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