Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Cool project bro
    by x1colegal
  • aiohttp vs httpx2?
    by vivzkestrel
  • https://news.ycombinator.com/item?id=49478655

    https://news.ycombinator.com/item?id=49479566

    by WalterGR
  • I thought we all moved over to Niquests and/or aiocquic and HTTP/3 these days.
    by cbsmith
  • HTTPX2 isn't a great name for a fork (or at all). Just leads to more confusion.

    Nevertheless, I'm curious about the pros and cons when comparing with "niquests".

    by dethos
  • Everytime someone is using httpx I always wonder why use that especially when niquests exists? I feel like it has always been such a better package
    by niltecedu
  • Also see the user’s other submission https://news.ycombinator.com/item?id=49477212

    “OpenAI: Migrating to HTTPX2” (github.com/openai)

    66 points | 1 hour ago | 50 comments

    by WalterGR
  • People should be aware how much worse HTTPX performs versus Aiohttp. For high scale systems it makes a massive difference
    by casper14
  • I keep confusing aiortc and aoc
    by qurren
  • AIUI the fork has better performance.
    by NewJazz
  • I can attest of that, and in addition of harmful decisions of the maintainer that are loaded foot guns...
    by greatgib
  • I searched and searched for way too long and could not find any information on whether or not aiohttp supports HTTP/2 or 3... do you know or have any reference that explains what all is supported?
    by ranger_danger
  • pyreqwest has been delightful so far: https://github.com/MarkusSintonen/pyreqwest

    It's been a pleasure to use, has a httpx compatibility layer, and it's fast (https://github.com/MarkusSintonen/pyreqwest/blob/main/docs/b...)

    by nateb2022
  • I would been pleased to see this project named something else, maybe “httpx-ng” or “httpy” as I immediately link “http*2” with the obsolete http/2 protocol and not the httpx project.
    by jenders
  • Ruby has httparty. https://github.com/jnunemaker/httparty
    by auvi
  • httpy is actually twofold cool for a Python HTTP client!
    by theanonymousone
  • I agree, the brain built in error correction makes it harder to read
    by brainzap
  • There is already a popular project called httpie, so httpy would be really confusing in non written form. Beside that, i completely agree, the name could be better.

    https://httpie.io/

    by Lindby
  • By what definition is HTTP/2 considered obsolete? Are you suggesting it's been supplanted by H3?

    (FWIW I agree w/ your objection to the "httpx2" name.)

    by chrisweekly
  • Noob question: what's the purpose of having so many request libraries? In JavaScript it's crazy, but in Python it's starting to feel the same: requests, httpx, httpx2...

    From my perspective, HTTP requests have been mastered for years (decades?). What's the point of switching libraries? What's so extraordinary about the new HTTP library that makes requests look crap?

    I understand that new protocols appear from time to time (like HTTP/2), but that's very rare. And if there are performance differences between two libraries, are they really that huge? Even if they are, 99% of people don't need that boost. What prevents someone from just improving the existing library's performance?

    by BoumTAC
  • Async ruins everything, as usual.
    by fulafel
  • There can be different APIs or different technical implementations with certain performance characteristics. In this case, there isn't any purpose, though. It's just that development has slowed or stopped on the previous libraries and forking/renaming is easier than trying to continue the previous projects, for various reasons.
    by globular-toast
  • HTTP is a pretty complex space once you get into the nitty-gritty of use-cases, common request handling patterns & conditional/dynamic header-definitions. In general this leads to:

    - (a) built-ins (& some libraries) being very verbose to use because they tend to take a "fundamentals of HTTP" approach & not implement shortcuts/common patterns

    - (b) libraries commonly falling into the trap of going the opposite direction & ending up with massive scope-creep and/or oversimplified, un-expressive APIs.

    This leads to a churn of libraries due to developers yearning for a Goldilocks implementation in between.

    Javascript tends to be ahead of other ecosystems in churn due to ease of library publishing, Python's catching up, but overall it's the same pattern in both.

    ---

    Also, one big additional factor is async:

    - NodeJS built-ins implemented a callback pattern just before promises took off, & have struggled to upgrade to promises cleanly without breaking backward compat.

    - Python's got a similar story with various generations of http library being sync, or relying on different async approaches in confusing ways.

    by lucideer
  • `requests` has a friendlier API than the standard library. However, it does not support newer versions of HTTP, nor does it support `async`. The maintainer considers it complete, feature-frozen software, IIRC - they'd rather keep it stable for existing users and let other libraries succeed it.

    `aiohttp` supports `async` but was never popular for non-async

    `httpx` supported newer HTTP versions and both async and non-async. However the maintainer decided to close all outside submissions, issues and discussions for personal reasons.

    `httpx2` is a maintained fork of `httpx`

    by t098i3