10231 Fix type annotation for inlineCallbacks

[richvdh]

Scope and purpose

Propagate the ReturnType of the generators wrapped by inlineCallbacks.

Contributor Checklist:

• The associated ticket in Trac is here: https://twistedmatrix.com/trac/ticket/10231
• I ran tox -e lint to format my patch to meet the Twisted Coding Standard
• I have created a newsfragment in src/twisted/newsfragments/ (see: News files)
• The title of the PR starts with the associated Trac ticket number (without the # character).
• I have updated the automated tests and checked that all checks for the PR are green.
• I have submitted the associated Trac ticket for review by adding the word review to the keywords field in Trac, and putting a link to this PR in the comment; it shows up in https://twisted.reviews/ now.
• The merge commit will use the below format
  The first line is automatically generated by GitHub based on PR ID and branch name.
  The other lines generated by GitHub should be replaced.

Merge pull request #123 from twisted/4356-branch-name-with-trac-id

Author: richvdh
Reviewer: 
Fixes: ticket:10231

Update the type annotation on `inlineCallbacks`.

[adiroiban]

Thanks for the quick PR.
Can we have it targeting trunk?

I will the cherry pick it in the release branch.

Thanks

[richvdh]

sure, done

[graingert]

I'm not really sure what the point of setting an accurate return type annotation on inlineCallbacks is at all. Currently the lack of ParamSpec support means the arguments of the decorated function can't be preserved, and if you can use return value syntax in a generator in your source code then you can use the preferred async/await syntax that supports Deferred annotations fully

[richvdh]

I'm not really sure what the point of setting an accurate return type annotation on inlineCallbacks is at all. Currently the lack of ParamSpec support means the arguments of the decorated function can't be preserved, and if you can use return value syntax in a generator in your source code then you can use the preferred async/await syntax that supports Deferred annotations fully

I don't agree with the last part of this. There are still situations where it is useful to use inlineCallbacks - and have it return a function which returns a Deferred of the right type. Two examples:

• You need to maintain compatibility with older code which expects a Deferred rather than a coroutine - either because the caller hasn't yet been converted to async/await or because you're preserving a public API.
• You're implementing an interface. For example, we have an implementation of IAgent, where IAgent.request is defined to return a Deferred - so an async function is not acceptable.

[graingert]

You can still make a deferred returning function from an async function, and it preserves the call signature:

async def _request(self, ham: int) -> None:
    await x

def request(self, ham: int) -> Deferred[None]:
    return Deferred.fromCoroutine(self._request(ham))

[richvdh]

You can still make a deferred returning function from an async function, and it preserves the call signature:

Well, I can, but the fact I can work around it seems a poor argument against improving the type annotation on inlineCallbacks anyway?

[graingert]

Newsfragment typo

[adiroiban]

Thanks you all for the contribution.

The news fragment make sense for me now.

As long as this change is not braking anything else, I think that is OK to merge it.

@graingert any comment against merging it?

[graingert]

closing and re-opening to kick off azure pipelines