Hi! Bob Kline schrieb am 12.10.2017 um 15:34:
On Wed, Mar 22, 2017 at 8:32 AM, Bob Kline 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.
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.
You likely didn't get a response because it's not entirely clear from your description what your use case is. In what way do you want to influence the behaviour of the resolvers based on that XSLT state information? Could you give an example of what that information looks like? PEP 550 would probably solve this, but otherwise, a stackish Python list in thread-local storage doesn't sound all wrong as an approach. Maybe hidden behind a context manager. Stefan