Naming for HTTP3 / Next-Gen HTTP client library

[sethmlarson]

NOTE: This discussion started within Team discussion before it was pointed out that the public could not see the discussion thread

This is a continuation of the discussion under python-http/python-http.org#3 about the naming for http3. There's also a good amount of public discussion on this issue on the http3 project.

To summarize those discussions the names that are candidates in any way are:

• http3 (Current name, confusing to users/common acronym conflict, especially if we don't support HTTP/3 right out the gate, is an acronym)
• https (Common acronym conflict, name we already have)
• hyper (Great name, currently an unmaintained but semi-frequently downloaded project by @Lukasa, name collision with python-hyper)
• fetch (Kinda related to HTTP, probably could grab from PyPI)
• requests3 (Lots of baggage, limits some design decisions)
• httpx

[sethmlarson]

@shazow:
I do like hyper, I'd also vote for https especially if it's a fully community driven project (ideally with support from PSF or something).

---

@njsmith:
Related discussion: python-trio/hip#84

---

@sethmlarson:
An excellent point that @tomchristie brought up about using acronyms that are common within the space we're working in (such as https, http3) is that it's impossible to distinguish between the package and the actual acronym being used. I'll add it to the list but it's definitely a valid point and a big reason I'm also leaning towards hyper if possible to use that name.

---

@sethmlarson:
I'll reach out to Cory about the name hyper and see what he thinks.

---

@tomchristie:
Coolio. As mentioned here, I think there's two tacks onto that:

• Make sure the next vesion includes an HTTPConnection class that errors with a "pin your dependencies" message.
• Actually implement an HTTPConnection class and continue to support the existing hyper API where possible, tho likely with a view to deprecating some bits come 1.0.

I havn't taken a serious look into how do-able the second option would be, but it would allow us to bring the existing hyper user-base along for the ride. It'd also help thrash out what stuff has Cory already dealt with in his implementation, that we also oughta be considering. On the flipside, it's not really the level of API we're actually aiming at (eg. its directly at the connection level, rather than connection pools, and it's a sync rather than an async interface).

---

@sethmlarson:
This might be a good use-case for pre-releases. Submit a release that deprecates the API then submit all of our patches until 1.0 as pre-releases so that non-prerelease users aren't impacted and hopefully pin before we ship 1.0?

[shazow]

FWIW, I don't think that https or http3 would be very commonly used as variables in these kinds of contexts. http, certainly. I imagine requests would be a more common variable people want to use than https.

[sethmlarson]

I'm not talking about variables necessarily. Think about things like talking to peers about the library, presentation slides. That's where it's tough to discern what is the library and what is an acronym.

[shazow]

Ah, that is true.

[graingert]

it would be confusing to me to make http (plaintext) requests with an https library

[graingert]

another option is to grab the 'http' name from PyPI

/cc @fcuny (owner on pypi) @rgsoda and @ajakubek (copyright holders)

[njsmith]

@graingert The python 3 stdlib already claimed http, so it's impossible to have a third-party package named that.

[florimondmanca]

I was thinking of httpx. It seems to tick all the following boxes:

• Does not conflict with a common acronym (https -> HTTPS, http3 -> HTTP/3)
• Does not conflict with (or sets expectations related to) an existing Python project (requests3 -> Requests)
• Does not use the name of an existing significant Python project (hyper)
• Does not conflict with an existing spec (fetch would make me think that the library mimics the Fetch API from JavaScript).

I like it because:

• It does not set any expectation other than being an HTTP library, and a next generation one (hence the x).
• The x makes me think of Learn X in Y minutes — we could list everything that's supported with a "where X=...` style: HTTP/1.1, HTTPS (TLS), HTTP/2, HTTP/3 (later), etc.
• I think it looks quite cool when actually used in code:

>>> import httpx
>>> r = httpx.get('https://httpbin.org/get')
>>> r
<Response [200 OK]>
>>> r = httpx.post('https://httpbin.org/post', data={'key': 'value'})
>>> client = httpx.Client()
>>> r = client.get('https://example.org/')
>>> r
<Response [200 OK]>

The name httpx is already taken on PyPI but the project is 0.0.1 and the GitHub repo doesn't even exist anymore, so it could be easily grabbed I think.)

I also did a quick Google search for httpx, and here's what I found:

• httpx libraries in Node.js and Elixir — they seem small in popularity, and even then I don't think it's a problem.
• A reference to an alleged HTTPX protocol used by Ketarin, apparently a Windows utility.
• Other than that, track's clear.

[graingert]

@kislyuk ^

[sethmlarson]

Thanks @florimondmanca, I'll add httpx to the list.

[shazow]

Ooo, I do like httpx.

Another strategy could be to do a survey of all the popular http libraries on other platforms. For example, npm has request (whose name predates requests). Rust has hyper. Go has http in the stldib 😍, and also a third party one named req. Ruby has excon, httpclient, http(.rb).

[graingert]

+1 for httpx
-1 for req, for the same reasons as requests3

[kislyuk]

Happy to hand over httpx, also would be interested in helping with the project.

[sethmlarson]

We'd love to have more contributors. :) If you're looking for direction you can contact Tom or I on Twitter or Keybase.