[Wishlist] A way to pass down custom data/context recursively to custom handlers.

[ks-mw]

I wish there was an easy way to pass some custom context/data down the recursive encoding to use it in my custom handlers.
In other words, I want to be able to set custom context/data that has the scope of a single call to encode/decode and can be accessed from inside the custom handler's methods.

Example (a new "context" argument is available in the custom handler's methods):

class A:
    ...

@jsonpickle.handlers.register(A)
class AHandler( jsonpickle.handlers.BaseHandler ):

    def flatten( self, obj: A, data: dict, context: dict ) -> dict:
        return do_something( context['foo'] )

    def restore( self, data: dict, context: dict ) -> object:
        return do_something_else( context['foo'] )

a0 = A()
a1 = A()

jsonpickle.encode( a0, context={'foo': 'bar'})
jsonpickle.encode( a1, context={'foo': 'baz'})

Is something like that planned? Or is there a trick I have overlooked that can be used to make such context data available in the handler?
A workaround I have come up with is to use some global state that is set before the call to encode and is then queried from inside the handler's flatten method. That however is very problematic for async code.

Best wishes,
KS

[Theelx]

I don't think there's builtin support for that currently, but that's a great idea! I'll see if I can get on it after I fix some of the bugs that have popped up.

[ks-mw]

Cool!
I am still wondering what the best signature would be. The context dict could as well be "object" instead I think. And a drawback of my suggestion is that the signatures for "flatten" and "restore" get bloated, which might annoy users who do not make use the context data.

[Theelx]

I don't believe the signature would get bloated, because context has to be an optional argument. Making it required would be a backwards-incompatible change, and I don't think it's a good idea to release jsonpickle 4 so soon after 3. Also, jsonpickle doesn't currently have typing information built-in because we only dropped support for CPython 2.7 with version 3.0.0, so the type signatures won't matter until I or someone else get to typing the codebase, which is likely fairly far into the future.

[ks-mw]

Ah yes, right.