You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One must run async for chunk in await async_response.iter_content() (which conflicts with the type hints provided for AsyncResponse.iter_content()) instead of the expected async for chunk in async_response.iter_content().
Expected Result
Content of the HTTP response to be printed in chunks to stdout.
Actual Result
Exception:
Traceback (most recent call last):
File "<redacted>/test.py", line 10, in <module>
if __name__ == '__main__': asyncio.run(_main())
^^^^^^^^^^^^^^^^^^^^
File "/home/james/.pyenv/versions/3.12.1/lib/python3.12/asyncio/runners.py", line 194, in run
return runner.run(main)
^^^^^^^^^^^^^^^^
File "/home/james/.pyenv/versions/3.12.1/lib/python3.12/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/james/.pyenv/versions/3.12.1/lib/python3.12/asyncio/base_events.py", line 684, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "<redacted>/test.py", line 7, in _main
async for chunk in resp.iter_content():
TypeError: 'async for' requires an object with __aiter__ method, got coroutine
It's true, something isn't right. But it is not what you think it is.
I suspect there's a bug (some edge case) that bring this bad UX. It does not seems to be something we can deal with within Niquests.
If you have a (rather clean, without breakage) solution that we can apply that makes both modern IDEs and mypy happy with, we'll proceed.
So there you have to await reproducer() as their is no yield within reproducer. This minimal code does not confuse mypy or IDEs. But Niquests makes it glitch somehow, making it "okay" to not await the method.
3.11.3 (2024-12-13)
-------------------
**Fixed**
- Static type checker getting confused around ``AsyncSession`` and
attached overloads (``AsyncResponse`` or ``Response``). (#185)
**Changed**
- Default keepalive (HTTP/2, and HTTP/3) changed to 1 hour. In
conformance with urllib3-future.
**Removed**
- Automatic resolution of pending lazy responses if there are too many
of them.
Previously, we hardcoded a limit of 128 * NUM_CONN_POOL maximum inflight
(aka. unresolved/lazy) response.
This was unrealistic due to a number of factors like (but not limited
to):
A) remote peers can choose at will the max streams.
B) we can have multiple pool with multiple (varying) max capacities.
C) retrieving max streams per pool per conn is a very costly procedure
(in terms of performance).
We will revisit this later on. You still can set
``max_in_flight_multiplexed`` in your ``HTTPAdapter`` to
restore this broken behavior.
One must run
async for chunk in await async_response.iter_content()
(which conflicts with the type hints provided forAsyncResponse.iter_content()
) instead of the expectedasync for chunk in async_response.iter_content()
.Expected Result
Content of the HTTP response to be printed in chunks to stdout.
Actual Result
Exception:
Reproduction Steps
System Information
Workaround
The text was updated successfully, but these errors were encountered: