41–50 of 194 posts
I'm not a lawyer, but are there any potential trademark issues? AFAIK in general you HAVE to change the name to something clearly different. I consider it morally OK, and it's probably fine, but HTTPXYZ is cutting it close. It's too late for a rebrand, but IMO open-source people often ignore this topic a bit too much.
What is it about Python that makes developers love fragmentation so much? Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, stdlib only has the ugly urllib.request, and everyone is using third party stuff like requests or httpx, which aren't always well maintained. (See also: packaging)
> Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024. This seems like a pretty good reason to fork to me. > Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, Or Javascript (well node), or golang (http/net is _wors…
I'm not a lawyer, but are there any potential trademark issues? AFAIK in general you HAVE to change the name to something clearly different. I consider it morally OK, and it's probably fine, but HTTPXYZ is cutting it close. It's too late for a rebrand, but IMO open-source people often ignore this topic a bit too much.
I think if had named it HTTPX2 or HTTPY, that would be much worse because it asserts superiority without earning it. But he didn't.
Earlier quoted context omitted.
Is it knee-quests or nigh-quests? I've started seeing these emoji-prefixed commits lately now too, peculiar
it's the gitmoji thing, I really don't like it, it was a mistake. Thinking to stop it soon. I was inspired by fastapi in the early days. I prefer conventionalcommits.org
> Visitor 4209 since we started counting Loved that little detail, reminds me of the old interwebs :)
Earlier quoted context omitted.
Oh i recognised one of the involved people immediately, drama person. I still think that hijacking the mkdocs package was the wrong way to go though. The foss landscape has become way too much fork-phobic. Just fork mkdocs and go over your merry way.
Drama around Starlette. Drama around httpx. Drama around MkDocs. I just hope that DRF is not next, I still have some projects that depend on it.
Earlier quoted context omitted.
it's the gitmoji thing, I really don't like it, it was a mistake. Thinking to stop it soon. I was inspired by fastapi in the early days. I prefer conventionalcommits.org
Please don't be too much inspired by FastAPI - at least regarding maintainer bus factor and documentation (FastAPI docs are essentially tutorial only), and requiring dozens of hoops to jump through to even open an issue.
What is it about Python that makes developers love fragmentation so much? Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, stdlib only has the ugly urllib.request, and everyone is using third party stuff like requests or httpx, which aren't always well maintained. (See also: packaging)
> Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024. This seems like a pretty good reason to fork to me. > Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, Or Javascript (well node), or golang (http/net is _wors…
What is it about Python that makes developers love fragmentation so much? Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, stdlib only has the ugly urllib.request, and everyone is using third party stuff like requests or httpx, which aren't always well maintained. (See also: packaging)
const response = await new Promise( (resolve, reject) => {
const req = https.request(url, {
}, res => {
let body = "";
res.on("data", data => {
body += data;
});
res.on('end', () => {
resolve(body);
});
});
req.end();
});More related drama: The Slow Collapse of MkDocs ( https://fpgmaas.com/blog/collapse-of-mkdocs/ )
Oh i recognised one of the involved people immediately, drama person. I still think that hijacking the mkdocs package was the wrong way to go though. The foss landscape has become way too much fork-phobic. Just fork mkdocs and go over your merry way.