I think the parent misunderstood "inability to get it passed through the Django module to the callback". At first it sounded to me like you were trying one of your own values.

But if you actually plan to use this code in production, I would strongly advise against it :). There is a better solution available that will survive django upgrades:

Add a middleware that stores the session object in a thread-local variable for the duration of that request. You can then access that variable from your event handler.

> Add a middleware that stores the session object in a thread-local variable for the duration of that request

This has come up many times, and I've never been able to figure out how to do this without something redis. Do you know any open source examples of this?

I am very confused how redis could get involved here. I hereby declare this open source :)

    import threading
    _local = threading.local()

    class SessionKeeperMiddleware:
        def __init__(self, get_response):
            self.get_response = get_response

        def __call__(self, request):
            _local.session = request.session
            response = self.process_request(request)
            _local.session = None
            return response


    def my_callback():
        do stuff with _local.session

Well, the idea is that I would have to store a variable and access it without races, so I would use an external storage library. This is pretty cool though, I've never used python threading for state, thanks a lot!

This doesn't use threading, just a thread-local variable (i.e. a variable that points to different memory locations for each thread) to make the whole thing threadsafe.

I don't have enough context to know if this will work in your situation, but I believe he meant something like the following:

  def create_callback(request):
      def invite_accepted(sender, email, **kwargs):
          request.session['invite_accepted'] = True
      
      return invite_accepted

You would then pass create_callback(request_object) as the callback, and would have access to 'request'.

This won't work since the request is not yet available when the callback is set up.

Yeah, that's why I said I wasn't sure of the context. :) I guess the middleware suggestion someone else posted is probably the idiomatic Django way, then.

In general this is why I don't like the direction Django is going. The Python idiom for this would be to create the callback as a closure after the request is available, and then pass it into the library function that calls the callback. I suspect you might still be able to do this, but you'd have to use a function-based view, and that's no longer idiomatic Django.

It seems like what Django folks want is to write a configuration markup language that is a subset of Python classes and not actually ever write any function bodies. The problem with this approach is that you're limited to the configuration points the framework gives you (in this case, the arguments passed to the callback). They can give you workarounds (i.e. middleware) but this is still fairly hacky. It would be better, IMHO, to stick with function-based views and provide library functions to do what the framework does, which can be called through function-based views in a way that's idiomatic with the host language.

But Django has gone too far down this path to change now, so I guess I just have to accept it. :)

correct