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
{{ message }}
This repository was archived by the owner on Apr 14, 2022. It is now read-only.
@njsmith and I discussed what the next steps would look like for Hip to become less like urllib3 and more like what users expect from a high-level HTTP client.
Make a v0.1 release with the current code-base before changing everything.
This will allow people including ourselves to play around with the code-base and
hammer on the implementation, especially the async implementation.
Make modifications to our unasync configuration to have two top-level names ahip and hip instead of hip._async and hip._sync. This will probably require a change in unasync to make it more generic?
Create a top-level async def request(method: str, url: str) -> Response function within the ahip namespace and add a simple unit test for the function. Figure out how in the future we'll be writing tests for both async and sync.
Hide all of the "urllib3" API. We could accomplish this by basically adding underscores in front of everything. Keep all the existing unit tests the same for now and replace all names with the new _-prefixed ones.
Start adding existing features to the top-level request() function. When functionality is added to the top-level function migrate those unit tests away from testing the internal APIs and to only use ahip.request() and hip.request().
From there we're well on our way towards a v1.0. Let me know if we forgot any steps that you think are important, there's obviously a lot of work to do in addition to what's listed above but hopefully we can focus on the above list to get us closer to a stable user-facing API.
Each of the above tasks can potentially be turned into their own issue when we start working on them?
@njsmith and I discussed what the next steps would look like for Hip to become less like urllib3 and more like what users expect from a high-level HTTP client.
This will allow people including ourselves to play around with the code-base and
hammer on the implementation, especially the async implementation.
unasyncconfiguration to have two top-level namesahipandhipinstead ofhip._asyncandhip._sync. This will probably require a change inunasyncto make it more generic?async def request(method: str, url: str) -> Responsefunction within theahipnamespace and add a simple unit test for the function. Figure out how in the future we'll be writing tests for both async and sync._-prefixed ones.request()function. When functionality is added to the top-level function migrate those unit tests away from testing the internal APIs and to only useahip.request()andhip.request().From there we're well on our way towards a v1.0. Let me know if we forgot any steps that you think are important, there's obviously a lot of work to do in addition to what's listed above but hopefully we can focus on the above list to get us closer to a stable user-facing API.
Each of the above tasks can potentially be turned into their own issue when we start working on them?