Skip to content

Version 0.11.0Β #724

Closed
Closed

Description

@lovelydinosaur

This one is a big deal, since it reintroduces the sync client, and is essentially a 1.0 pre-release in terms of how the API looks.

>>> import httpx
>>> httpx.get('https://www.example.com')
<Response [200 OK]>

πŸŽ‰βœ¨ TA-DA! βœ¨πŸŽ‰


Release notes

0.11.0 (January 9th, 2019)

The 0.11 release reintroduces our sync support, so that httpx now supports both a standard thread-concurrency API, and an async API.

Existing async httpx users that are upgrading to 0.11 should ensure that:

  • Async codebases should always use a client instance to make requests, instead of the top-level API.
  • The async client is named as httpx.AsyncClient(), instead of httpx.Client().
  • When instantiating proxy configurations use the httpx.Proxy() class, instead of the previous httpx.HTTPProxy(). This new configuration class works for configuring both sync and async clients.

We believe the API is now pretty much stable, and are aiming for a 1.0 release sometime on or before April 2020.

Changed

  • Top level API such as httpx.get(url, ...), httpx.post(url, ...), httpx.request(method, url, ...) becomes synchronous.
  • Added httpx.Client() for synchronous clients, with httpx.AsyncClient being used for async clients.
  • Switched to proxies=httpx.Proxy(...) for proxy configuration.
  • Network connection errors are wrapped in httpx.NetworkError, rather than exposing lower-level exception types directly.

Removed

  • The request.url.origin property and httpx.Origin class are no longer available.
  • The per-request cert, verify, and trust_env arguments are escalated from raising errors if used, to no longer being available. These arguments should be used on a per-client instance instead, or in the top-level API.
  • The stream argument has escalated from raising an error when used, to no longer being available. Use the client.stream(...) or httpx.stream() streaming API instead.

Fixed


What's next...

I'd expect that we'll likely end up waiting for a period of time after this release, and then end up releasing a 1.0 with either no API changes, or only very minimal API changes. (The only remaining area I can see us still wanting to refine/change, would be some review making sure we've got an exception heirarchy/naming that we're entirely happy to stick with for 1.0 onwards)


Checklist

Activity

  1. added this to the 0.11.0 milestone on Jan 6, 2020
  2. florimondmanca commented on Jan 6, 2020

    @florimondmanca
    Contributor

    I think the breaking in this release should not be underestimated from a user perspective. Granted, we’re still pre1.0, but a second abrupt round of breaking changes after 0.8 dropped sync might not be what we need.

    So while I agree with basically reswitching from async to sync as the default, I’m thinking of ways we could help users migrate.

    At the very least we could probably add a migration guide item to this checklist, as a prose-form and hand-guided tour of the change log, with hints on migrating a codebase that uses 0.10. Thoughts?

  3. lovelydinosaur commented on Jan 6, 2020

    @lovelydinosaur
    MemberAuthor

    Things we could potentially could defer, pass-on, or mitigate: #678, #723.

    The big one is the sync API, which for our existing users means...

    • Always use a client instance.
    • Use the httpx.AsyncClient() naming.

    If we're very clear about that, then I think the "okay we're done here API-wise" trade-off is probably worth it?

  4. florimondmanca commented on Jan 6, 2020

    @florimondmanca
    Contributor

    Yes, those recommendations sound like a good plan to provide some proactive communication. Should we roll them out now, i.e. some time before 0.11 is out?

  5. StephenBrown2 commented on Jan 6, 2020

    @StephenBrown2
    Contributor

    Still itching for httpx-native Retry functionality as a 1.0 API feature...

  6. lovelydinosaur commented on Jan 6, 2020

    @lovelydinosaur
    MemberAuthor

    Sure, I could potentially see us including that.

    Few things higher up on the priority list still atm, and wouldn’t strictly need to be a 1.0 feature (ie add more features/API post 1.0 is totally fine, the cutoff is for making sure any API we have introduced is in a final state.)

    But yeah may not be a bad idea.

  7. iwoloschin commented on Jan 7, 2020

    @iwoloschin

    A big +1 for built-in retry, though I've made a very simple and very silly recursive retry wrapper that appears to work reasonably well, other than polluting up your stack trace when something does go wrong.

  8. lovelydinosaur commented on Jan 7, 2020

    @lovelydinosaur
    MemberAuthor

    Dropping #678, #723 since they're not really a hard requirement here.

  9. jayvdb commented on Jan 8, 2020

    @jayvdb

    Note 0.10.1 hasnt been tagged.

  10. unpinned this issue on Jan 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsChanges to the documentation

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions