Ensured explicit closing of async generators

[agronholm]

Summary

This change ensures that async generators are always explicitly closed, even if the task running the generator is cancelled or another exception is raised. This prevents unpredictable behavior and also avoids the asyncgen finalizer warnings on Trio.

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

[agronholm]

Note that this depends on another PR: #3592. I will mark as ready to review once that one has been merged.

[agronholm]

I checked locally with Python 3.10 that the supposedly missing coverage cannot be reproduced. I'm seeing 100% coverage, even without the httpcore changes.

[agronholm]

I checked locally with Python 3.10 that the supposedly missing coverage cannot be reproduced. I'm seeing 100% coverage, even without the httpcore changes.

Never mind, I was on the wrong branch. Fixing.

[agronholm]

@Kludex All good now.

[Kludex]

Why is the async removed?

[agronholm]

It's not really necessary here. __aiter__() can return any arbitrary object that supports the AsyncIterator protocol, and the implementation here just raises NotImplementedError.

[agronholm]

@tomchristie this is not an important part of this PR so if you object, I can just revert it.

[agronholm]

On another note, is either one of you at EuroPython?

[Kludex]

On another note, is either one of you at EuroPython?

I'm not. 😞

[lovelydinosaur]

Interesting. I'm curious about this vs. aclosing.

https://docs.python.org/3/library/contextlib.html#contextlib.aclosing

[agronholm]

I originally went with aclosing() but it doesn't work very well with arbitrary async iterables.

[lovelydinosaur]

👍🏼 Neat.

[lovelydinosaur]

Thanks for your time on this @agronholm.

The 1.0 pre-release deals with this comprehensively. There's no I/O iteration or generators, just regular .read()/.close() for I/O, as well as a much simpler callstack.

[ofek]

I haven't been following the developments. Are the changes you mentioned due to performance?

[agronholm]

I haven't been following the developments. Are the changes you mentioned due to performance?

No, but correctness. Async generators are supposed to be explicitly closed when you're done with them. But this PR is obsolete as httpx is transitioning to a new API in which I'm told this is a non-issue anyway.

[ofek]

My apologies for not being explicit, I was referring to the removal of generators/the new design. I'm always interested in hearing about architectural changes to this library because at work we have a task I created a while back to deprecate our use of requests on customer machines. I'm no longer on that team, but I try to update the task description over time with tips or best practices for the eventual migration.