Picking a good name

[njsmith]

Picking a good name

[njsmith]

We are now hip.

[njsmith]

Rough draft for logo:

(Does anyone know how to say "http client" in the Black Speech?)

[njsmith]

Update: I sent @jgors an email last weekend asking if he'd be up for giving us the hip name. No response yet. I guess I'll try pinging again this weekend, or maybe ping one of his co-authors I know to see if he has better contact information :-). If we can't get in touch then we can always ask the PyPI admins to transfer it under the PEP 541 rules for name squatting, but I'd rather work it out directly if we can...

[theacodes]

@shazow probably has thoughts here.

I would name it something like connectionlib or connections (mirroring requests). Connections is taken on PyPI, but its an inactive project so we may be able to snag it.

[njsmith]

Connections is taken on PyPI, but its an inactive project so we may be able to snag it.

PEP 541 says that in a case like this, the only way to snag an inactive project is to convince the current owner to voluntarily hand it over; if the owner is AWOL then too bad. So I'd probably try for something else...

It'd be nice if urllib3 and requests could move more towards each other... I know there are complications (maybe we can talk about that next week @ pycon?), but there's no a priori reason there should be one lib that's powerful and one with better defaults.

[shazow]

I don't recommend urllibN, that is one of my regrets as far as naming goes. :)

I definitely support better defaults for urllib3, there's no reason to make things hard on people.

A few questions:

• Is your goal to have this fork be a standalone project? Or are you expecting it to be merged into urllib3 or requests? Or will it be a component of urllib3 or requests?
• Is it focused on HTTP specifically, or more of a generic async connection pooling? (Would it work, for example, with database socket connections?)

If you imagine the possibility of it being a stand-alone project, it's worth naming it as something that sounds standalone.

I'm also confident you'll be able to claim a PyPI name if there is one you like and it's inactive. :)

I'll try to come up with some name ideas!

[njsmith]

The goal is essentially to be urllib3 v2. Like, that's literally the branch we started with, and we're still managing to merge in changes from urllib3 master (though it's getting harder). So the goal would be to eventually replace urllib3 wherever it's used, including in requests. The exact details are up for discussion – I guess there's a mix of technical and non-technical considerations there. We're breaking compatibility in some ways, because it's necessary for new features or just to clean up old stuff, but we're trying to not go overboard with that, because we want to make it really easy for people to migrate.

For now it's http/1.1 only. It'd be neat to support http/2, and maybe websocket (esp. since http and websocket can now be multiplexed over the same connection), but that's for the future. I think general connection pooling is definitely out of scope though.

There's no particular desire to keep it a separate project, we've just been slowly pecking away at it here because, you know, the hardest problem in computer science is talking to other people.

[shazow]

@njsmith I think this is the right move. It's really hard to coordinate this kind of big change, especially with limited resources on both ends. Maybe some public user testing and adoption will make everyone more comfortable to just yolomerge it? (I honestly don't have feelings against this, but I'm not as intimately familiar with our ongoing challenges as I was before.)

If you want to be tied to the urllib3 name, could go with something like urllib3-async.

I know https on PyPI is unused which would be a cool name for yet another high-level http library someday. I registered it a long time ago and gifted it to @Lukasa in case he wanted to push out Hyper into a standalone next-gen http/2 lib someday.

Or maybe even http-async could work, if it makes sense to highlight the async thing as a differentiator.

I'll think of some non-http related ideas too.

[njsmith]

it makes sense to highlight the async thing as a differentiator.

Hmm, I don't think this is how I would market it! That's a useful thing to learn :-).

I don't think the distinguishing feature is that it's an async http client; there are lots of those. I think the distinguishing feature is that it's a universal HTTP client – it supports sync, it supports all the different async variants, no matter your context you can use this client.

If we want to build on that, maybe something like "uhttp, the universal http client"? (uhttp is indeed free on pypi.)

[pquentin]

For reference, another option is requests-core. https://pypi.org/project/requests-core/ from @kennethreitz is an early snapshot of our urllib3 bleach-spike branch with various classes renamed.

I'd be happy with any name. uhttp and the associated logo are nice!

[RatanShreshtha]

What is the idea behind logo ? uhttp is also good.

[njsmith]

The "logo" is a joke – that image is the "one ring" from the lord of the rings ("one ring to rule them all")

[RatanShreshtha]

@njsmith okay got it, I have not seen The Lord of the Rings so did not get the reference, so we can also have a tag line something like one client to work with all sync, async

[njsmith]

It turns out there are half a dozen other "uhttp" libraries out there (they mean "micro-http").

uhc, the universal http client? Amazingly this is actually not taken on pypi. But searching "uhc" is overwhelmed with hits for a health insurance company, and "uhc python" is a bunch of gun stuff, so meh.

[njsmith]

More ideas:

• ofa: "one for all" (free on pypi)
• hip (squatted on pypi, but last update was 2013 and has never had a release, so reclaimable)
• hype (squatted on pypi, but last update was 2013 and has never had a release, so reclaimable)

I kinda like hip...

[RatanShreshtha]

What about weblibx or uweblib ?

[pquentin]

I prefer the names that mention HTTP, and it's even better if there's the universal idea. Which is why I like uhttp! I don't think libraries in other languages should be an issue. The important search term is " python". uhc and hype fail here, but uhttp, hip and ofa work fine.

Other ideas:

• utransfer (using the second T in http)
• unihttp (uni for universal)
• ubihttp (ubi for ubiquitous)
• tellurian (using a thesaurus for universal)
• I liked omnibus (in the "present in all places and at all times" sense) but it's taken for a small PyPI project

But again, +1 for uhttp

[RatanShreshtha]

+1 for unihttp and tellurian

[njsmith]

Apparently "tellurian" is a word for "inhabitant of earth"? I've never heard of this word before :-)

To me "utransfer" parses like "you transfer" – in america, "U-Haul" is the best-known company for renting a truck to move houses, when you don't want to hire people to do it for you. So it sounds like a play on that. Not necessarily a bad thing, but it doesn't communicate "universal".

Another idea I found in notes: GotIt (import gotit). Like hip, it has pre-existing positive connotations.

[pquentin]

Oh, hip is not only about the body part :D Sounds good too!

[njsmith]

https://github.com/pypa/warehouse/issues/6690

[pquentin]

I think the Lord of the Rings logo would still make a good logo?

[sethmlarson]

@pquentin I've got a logo idea in my head. :) I'll create a mockup soon.