[lovelydinosaur]

I wanted to checkout adding async support, so here's a first pass at that...

$ uv run python -m asyncio           
>>> import asyncio
>>> import hip
>>> async with hip.Client() as c:
...     r = await c.get("https://www.encode.io/")
...     print(r)
...     
<Response [200 OK]>

[lovelydinosaur]

@cgl Realise this is a big design question to have on a project that's otherwise becoming fairly well defined, though... ...there's an obvious question here.

Which of these platforms are we aiming for?... ...either or both?

[cgl]

Which of these platforms are we aiming for?... ...either or both?

I think we want to support both styles, so we might look for a way to add async support, not replacing sync with async? What do you think? Any cons or blockers there?

[lovelydinosaur]

The namespacing is sorta the tricky bit. Helpful that our requests and responses are actually immutable and don't have any I/O directly. Eg. We're able to support request.content.open() and await request.content.aopen().

[lovelydinosaur]

I think we want to support both styles, so we might look for a way to add async support, not replacing sync with async? What do you think? Any cons or blockers there?

It would actually sort have made more sense to start with async, because...

• async -> sync isn't complicated.
• expect that the async version of our server oughta hold up pretty well.

We could either...

• switch up to async-first now before we've got versioning concerns, and then add the sync version.
• look at adding async alongside the sync version.

Here's how a mirrored layout might look...

backends/
    anyio.py
    asyncio.py
    sync.py
    trio.py

core/
    content.py
    forms.py
    headers.py
    queryparams.py
    request.py
    response.py
    urlencode.py
    urlparse.py
    urls.py

async/
    client.py
    server.py
    streams.py
    parsers/
        httpparser.py
        readaheadparser.py
    transports/
        base.py
        connectionpool.py
        connection.py

sync/  # mirrored with `unasync`
    client.py
    server.py
    streams.py
    parsers/
        httpparser.py
        readaheadparser.py
    transports/
        base.py
        connectionpool.py
        connection.py

That's assuming we actually want to support both styles. The alternative is we just be super clear about a design choice, only support eg. async, and guide our users towards what we think is the best choice in python circa 2026.

In terms of documentation that'd be a sharper choice. Although covering all the bases has v obvious advantages.