Thanks, I’m still trying to figure out exactly what mechanisms work best for this to annoy the fewest people. For example, the contribution guide mentions that PRs should be a single commit, so does this mean that with draft PRs I’d need to keep
force-with-lease pushing to the same branch? What about when someone has already reviewed it (I’m not sure if force-pushing erases comments on Github or anything like that)?
The PR is here and does point back to the ticket (here). It’s basically looking to make builtin decorators be able to handle both sync and async views without the need for additional
@async_to_sync around them.
I’ve got what I think is a workable solution up, based on the discussion in the ticket, although there’s a lot of repetition so I’m trying to see if there’s a nice way of wrapping the main
process_response function (which is the only thing that’s different in all of the functions). I’d be super keen for any pointers or obvious issues as it’s my first real foray into async things.