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.

[kislyuk]

OK. Which PyPI users should I add as owners in httpx?

[sethmlarson]

SethMichaelLarson and tomchristie should be fine. cc: @tomchristie We won't start using it until we come to a consensus here though.

[tomchristie]

I guess we're leaning towards httpx here(?)

@sethmlarson did ya get any thoughts from Cory on if revitalising hyper would be a go-er instead? Is that just an overcomplication?

Personally I'm not totally against considering a requests3 if it came with a clean slate wrt. funding/branding/maintenence (I still think there's an argument to be made there wrt. continuity being in the community interest) but I've not heard anything from KR around this, and I know there's a bunch of (legit) pushback against that here in any case, so.

[sethmlarson]

I've reached out to Cory just today, dropped the ball a bit on my side. :)

[kislyuk]

Added @sethmlarson and @tomchristie as owners of https://pypi.org/project/httpx/.

[N-Coder]

I'd prefer hyper to httpx as it is a lot easier (and cooler) to pronounce 'hai·puh' as a word than 'eich-tee-tee-pee-eks' as an abbreviation. Additionally, both could mean something related to any version of HTTP, but hyper follows a similar logic as requests, fetch, and the like. So I'd vote for revitalizing it, if that's not too much work.

[sethmlarson]

I'm in discussion with Cory right now about what he'd be comfortable with with revitalizing hyper. I think we should use it if the procedure we agree on is acceptable to others. :)

[sethmlarson]

Cory and I have reached an agreement with hyper. Our discussion on Twitter:

---

@sethmlarson:

Our thought process was basically: Upload a release that's +patch that emits a warning on first use with a description about what's going to be done. After some time with that active start making pre-releases with the new API, then once we've reached v1.0 some time later we start releasing non-prereleases.

---

@Lukasa

I’m happy to run with that approach

---

@sethmlarson

Great! We can get a little bit of work done on our side to create a landing point for users with questions / issues and what to do if they don't want to opt in to changes.

After that work is done we can make the PR on the python-hyper/hyper repository to add the warning in a way you're happy with. Then maybe add Tom Christie, Nathaniel and I to the PyPI project and we'll make our first prerelease in 2-ish weeks after that happens?

Does that sound acceptable to you?

---

@Lukasa

Sure, sounds good, but I may just also bring you all on to the project and just file an issue announcing that I’m handing over control to you. Should make it a bit easier on you.

---

Given this are we all in favor of using hyper?

[sethmlarson]

Cory has added @tomchristie, @njsmith, and I to the hyper project: python-hyper/hyper#415

[tomchristie]

🤩 Yup that sounds ace. Not quite sure how we’d want to marshal the organisation name vs. the package name. (Eg are we expecting “hyper 1.0” to land on the existing python-hyper org, or here on python-http?)

I think the two different docs pages for the hyper org vs the hyper package are possibly a bit confusing for newcomers, as they currently stand:

https://python-hyper.org/en/latest/
https://hyper.readthedocs.io/en/latest/

[sethmlarson]

1.0+ would land on python-http and the old repository would remain for the pre-1.0 version and updated with a proper message regarding it's status.

There's a good amount of naming issues to figure out, I think we'd be fine using hyper.readthedocs.io for hosting our new documentation since it's related to the client library hyper and not the organization python-hyper.

[tomchristie]

Any thoughts on how to have a clearer seperation between the existing python-hyper GitHub org, and the python-http/hyper package?

I'm super keen on this, but I'd quite like to get straight in my head what GitHub orgs and what documentation domain names we'd be transitioning too.

(Also: @kislyuk - thanks so much for having made httpx - really appreciated, even if it doesn't look like that's where we'll end up)

[njsmith]

Stray thought: repurposing hyper seems like it involves a bit of hassle -- what about hype? It's squatted on PyPI, but has never had a release and the homepage is 404, so I think under the usual PyPI rules we can reclaim it: https://pypi.org/project/hype/

[sethmlarson]

Even with the repurposing issue I think I'm still leaning hyper. 1-to-1 with HTTP, speed connotations, other langs use hyper. Hype is a great name though! Excellent find :)

[sethmlarson]

Plus I'm actually thinking revitalizing the project is a great way for us to get some early users, especially those interested in next-gen HTTP.

[njsmith]

Again, I don't have a strong opinion, but since arguing is a FOSS dev's favorite sport:

1-to-1 with HTTP,

They're both prefixes of HTTP...

speed connotations,

"Hype" is slang for "excitement", so the connotations work either way.

other langs use hyper.

Usually "there are confusingly similar projects already using the name" is the biggest reason to avoid using a name!

[njsmith]

Oh and:

Plus I'm actually thinking revitalizing the project is a great way for us to get some early users, especially those interested in next-gen HTTP.

While breaking people's existing, working setups is certainly an effective way to get their attention, I'm not sure it's going to get the reaction you're hoping for.

[sethmlarson]

You're definitely right, I'd love to hear other's thoughts too.

[graingert]

I believe the plan is the this will be released as 0.x.y.az and then 1.0.0 so it won't break anyone using semver requirements

…

On Tue, 16 Jul 2019, 23:45 Nathaniel J. Smith, ***@***.***> wrote: Oh and: Plus I'm actually thinking revitalizing the project is a great way for us to get some early users, especially those interested in next-gen HTTP. While breaking people's existing, working setups is certainly an effective way to get their attention, I'm not sure it's going to get the reaction you're hoping for. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AADFATHRDIXBLRPTDLRTKKTP7Y6BRA5CNFSM4H7F3NJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2CHZPA#issuecomment-511999164>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADFATBEA7HFZBW2G3OUDXLP7Y6BRANCNFSM4H7F3NJQ> .

[sethmlarson]

Being distinct from existing docs and other languages is kind of nice. Completely clear slate name-wise, all the other options we've suggested are either used by another lang, are an acronym, or already have history.

[shazow]

Personally, I like hyper >= httpx > hype.

I acknowledge that there may be some people who become frustrated with hyper's transition, but realistically hyper has not been updated in over 2 years, and any transition shouldn't be very painful (going back to pin a version, or switch to the archive repo).

In general, my advice is: Don't let fear of breaking things get in the way of progress. If there's a possibility of moving forward past the really really really really socially and emotionally difficult problem of choosing a name, err on the side of breaking things if that's what it takes. Not advocating breaking things just for fun, but breaking things for progress is worth it for everyone involved. The community will benefit the sooner and the more enthusiastically this project moves forward. :)

[njsmith]

I believe the plan is the this will be released as 0.x.y.az and then 1.0.0 so it won't break anyone using semver requirements

That's fine if people are using the appropriate constraints already, but are they? My experience has been that once you've break someone's setup, then explaining how it's actually OK because of some retroactive justification you made up usually doesn't make them any happier...

It does look like hyper only gets ~70k downloads/month, and github estimates it's used by 223 repos and 32 packages, which is non-trivial but on the low end.

It looks like Rust currently owns the hyper tag on SO: https://stackoverflow.com/questions/tagged/hyper

[tomchristie]

I'm probably warmer on httpx than hype. (Also the name has a fairly empty search space at the moment.)

I really like hyper and I don't think there's any significant issue wrt. a complete API overhaul for a 1.0 vs. the existing version (pretty standard stuff) but I do think we'd need to transition some stuff so we didn't end up with:

• https://github.com/python-http/hyper
• https://github.com/python-hyper/
• https://github.com/python-hyper/hyper-h2
• https://github.com/python-hyper/h11
• https://github.com/python-hyper/hyper
• https://github.com/python-hyper/{various-other-projects}

Ideally I'm much rather end up with something like:

• https://github.com/python-http/hyper
• https://github.com/python-http/h2
• https://github.com/python-http/h11
• https://github.com/python-sansio/{various-other-projects} # Or some other name

[sethmlarson]

To compliment @njsmith's comment on StackOverflow tags: httpx is not taken by any language.
If enough people are happy or okay with httpx I think we should use it to get over this hurdle. :)

[tomchristie]

I can roll with that.

[tomchristie]

-> encode/httpx#129

[sethmlarson]

We've decided on using HTTPX and the latest version of the project has been released to PyPI. Massive thank-you to @kislyuk for the name httpx ❤️

Thanks all for participating in this discussion, I hope to see the same fervor on other discussions as well. ;)

[jlaine]

Awesome, I'm glad we didn't end up with https / http3 and I like httpx :)