Deprecate support for wrapping sync things as async

[adriangb]

There are several issues related to wrapping sync things to make them async:

• Improve detection of async callables #1444
• Preserve changes to contexvars made in threadpools #1258
• Starlette and pandas results in unreleased memory piling up when using sync endpoints #1573 (comment)

Are a couple I can think of.

A comment from Tom: #886 (comment)

In the interest of keeping Starlette minimal, I think we should deprecate and later remove this functionality.
Downstream consumers can choose to vendor this functionality (it's only a couple LOC) since they'll have more control over the rough edges by virtue of being less general of a framework.

[adriangb]

cc @Kludex

[Kludex]

I'm not into this idea. 😕

[adriangb]

Yeah that's fair, I don't expected to be without opposition. Would you mind summarizing your thoughts on why we should provide this functionality to users?

[Kludex]

I don't think the arguments for removing it are strong enough. There's not much to express from the status quo side.

[adriangb]

Yep understandable.

My main thoughts for removing it is:

• It's better to be explicit. As we now know, this automatic wrapping can lead to surprising behavior with contextvars or detection of coroutines. This can confuse users, as evidenced by the multiple related issues, some of which have dozens of likes, and the fact that the resultant behavior is hard to explain even for advanced developers (e.g. Sebastian's comment in the upstream FastAPI issue, and frankly this stuff confuses me as well)
• It's 1 LOC / decorator for users to wrap their own functions.
• We would remove quite a bit of tricky logic from Starlette (what we have there now, but also what we save in the future by not merging Improve detection of async callables #1444 or Preserve changes to contexvars made in threadpools #1258)