Earlier quoted context omitted.
Is it knee-quests or nigh-quests? I've started seeing these emoji-prefixed commits lately now too, peculiar
There is a series of extensions for Vscode that add this functionality like https://github.com/ugi-dev/better-commits
Why I forked httpx
31–40 of 194 posts
Re: Why I forked httpx
#32What 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…
Re: Why I forked httpx
#33Re: Why I forked httpx
#34What 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…
Instead, official documentation seems comfortable with recommending a third party package: https://docs.python.org/3/library/urllib.request.html#module...
>The Requests package is recommended for a higher-level HTTP client interface.
Which was fine when requests were the de-facto-standard only player in town, but at some point modern problems (async, http2) required modern solutions (httpx) and thus ecosystem fragmentation began.
Re: Why I forked httpx
#35Re: Why I forked httpx
#36Re: Why I forked httpx
#37Earlier 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.
Re: Why I forked httpx
#38Re: Why I forked httpx
#39I'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.
Re: Why I forked httpx
#40I'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.