Blockers for 1.0 release.

List of things that I currently think are required for a 1.0 release.

We should try to keep this scope as narrow as possible. Anything related to the external API is fair game, plus any critical level implementation issues.

Anything else that doesn’t meet those criteria should be regarded as not strictly required for 1.0.

• Implement parallel requests. (See #52)
• Make URL support str comparison. (See #113) Easy contributor issue
• Finesse URL interface, focusing on str vs bytes and escaped vs non-escaped. (eg. nail down questions like - does authority return a string that’s idna-escaped or not?)
• Finesse stream interfaces. (Both upload and download. Eg. response.raw and response.stream are currently a bytes async iterator. I think we probably want it to be a stream interface. Related to #123, #24)
• Review auth and/or retry interface. (We have a dispatcher interface already, but it’s overly involved for what we really want here. Requests uses callback hooks for more complex cases here, see https://github.com/encode/httpx/pull/136#discussion_r305946280 but I’m not super keen on that. A simple middleware interface might be appropriate(?) and would be sufficient for both retries and auth requirements. (Related to #295, #345)
• Review potentially critical issue #96
• I don’t think the read/write timeout switchover is quite right yet. (Related to https://github.com/encode/httpx/issues/191)
• I think we’ve got some outstanding race conditions if a Client is used w/ multi-threading. asgiref gets it right - need to take the same kind of approach.
• Finish documentation. Esp “Advanced” section, and API docs. (Related to #343)
• Ensure alternate concurrency backends are adequately supported. (Not neccessarily in core, but really would like to concretely demonstrate that we’re providing adequate API to support that use-case) Refs #120
• Review exception heirarchy, and any API on exceptions. (Related to #141)
• Review dispacth interface.

Am I missing anything else that strictly needs to get onto this list?

[florimondmanca]

I went ahead and pinned this issue, as well as marked a bunch of issues (some of them already closed so we don’t feel like everything remains to be done 😄) as part of v1.0: https://github.com/encode/httpx/milestone/1. I also edited the issue description with more related issues so we can better see whether we addressed the various points in the near future.

[tomchristie]

Personally, I’d prefer not too. Or at least not unless we’re streamlining a whole bunch of related projects under python-http. As long as it’s something under encode I’d like to see it in-line with how other projects in this org are being managed - that keeps things simple from my POV.

Instead I’d rather get around to adding better interlinking and API docs generation to mkdocs.