Resp prepare

[asvetlov]

Signals support is very important for aiohttp.web, I see strong request for the feature.
We have a PR for that #439 (@alexsdutton, thanks a lot BTW for your work)

I insist signal handlers should be coroutines. Just signal callbacks are very subtle: we may want to access, say, database for modifying response headers (the main purpose for signals right now).
Keeping both synchronous and asynchronous signals just makes a mess -- signals should be coroutines. Period.

Thus I propose deprecation StreamResponse.start(requiest) method in favor of StreamResponse.prepare(request) coroutine (.begin() is an option but I feel .prepare() is better name).

The change is backward compatible with limitation: old code still may use resp.start(request) way but we will not apply signal handling for it.

New code should use .prepare() with benefit of signal handling.

Any objections? @fafhrd91 @kxepal

TDB:

• Make tests for backward compatibility (use resp.start() and catch a deprecation warning). We should do it at least for keeping our test coverage level.
• Update docs with marking .start() deprecated and forcing to brand new .prepare() usage.

[kxepal]

Seems .start remain plain old function while .prepare is coroutine. Are they really interchangeable during deprecation period?

[asvetlov]

They are do interchangeable with a note: .prepare() will process signal handing for response sending but .start() will not.

[kxepal]

Good to know.

[fafhrd91]

I do not like prepare coroutine, right now there is no real use case for coroutine signal. And database example is very good way to shoot yourself in the foot. You should realize, if you give users a gun they for sure shoot themselfs and they will blame you.

Python is not fast, and adding more to hot execution path making aiohttp slower.

But you are free to add this change, just be cearfull I do not want end up in situation like 0.12 and 0.15

[asvetlov]

The change is backward compatible (all existing code will continue working but for new code .prepare() is preferable way).
Yes, user can shoot himself by adding slow signal handler which is called on every request.
The same is true for middlewares, BTW.
Keeping current .start() and sync signal handler for started request just leads to dirty trick.

In practice users will

1. create middleware
2. calculate all required data on middleware entering
3. store it in request object
4. move the stored data into response headers in signal handler

I'm not finding the way is elegant.

[asvetlov]

Finally ready for merging.

[lock]

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.