Michiel's Blog

Talk at PyGrunn on httpxyz

2026-05-03T22:00:00+02:00

On Friday 8th of May 2026 I will be giving a talk on our new fork of the popular python package httpx called httpxyz at PyGrunn. PyGrunn is a full day Python (“and friends”) conference in Groningen, The Netherlands. httpx is a top-100 Python package for sending http requests but has not had a release since end of 2024, plus, recently all issues were set to hidden and all discussions are closed. httpxyz is our friendly fork with lots of fixes for serious and more niche issues. Read for more info my announcement post for httpxyz. I will talk about why we did the fork and how we approach it. I’ll also delve into how to build a performant API client in Python and technical details of HTTP.

This is an expanded version of the talk I gave at PyAmsterdam last week, and is part of my ‘promotion efforts’ for httpxyz. I look forward to giving my talk & see you there!

httpxyz one month in

2026-04-27T09:00:00+02:00

It has been roughly a month since we forked httpx and named our package httpxyz. For the reasons why I refer you to Why I forked httpx. In this post I will explain where we are now, one month ‘into’ having created the fork.

TL;DR: httpxyz has now many bug fixes and significantly better performance than httpx, and we would encourage anyone to move to our version!

Where we are now

Initial version of fork

Our first version of httpxyz contained just the fixes to get zstd working, and the fixes to get the test suite running on python 3.14, some ‘housekeeping’ changes related to the renaming, as well as some minor and trivial fixes that had already been merged in httpx and had not been released yet.

End of March: bugfixes, and performance improvements

Then at the end of March we did another release of httpxyz, containing a compatibility shim that allows you to use httpxyz even with third-party packages that import httpx themselves, as long as you import httpxyz first. We’ve added a nice documentation page for this.

This release also included a change that lazily imports the CLI for httpxyz, which is typically not used in your app; in my measurements this makes httpxyz import in half the time needed by httpx. This PR has been sitting idle at the httpx repository for over a year ref and we’ve kindly adopted it, thanks to Nate Hardison for providing it!

And apart from that we adopted a bunch of other smaller and bigger bug fixes and improvements in this release.

httpcorexyz!

But we realized pretty soon that there were some problems that httpx was having, that were actually caused by the underlying ‘transport’ which is defined in a different module, httpcore. This module also had no release in over a year, and there were a bunch of issues reported by users, with fixes even, that were not landing. So we ended up also forking httpcore and created httpcorexyz.

Here we fixed a WHOLE bunch of performance related issues:

Use anyio.Lock(fast_acquire=True) and anyio.Semaphore(fast_acquire=True) to skip unnecessary event loop yields on uncontended lock acquires. Reduces async GET latency by ~3.3x. Reinstates encode/httpcore#953 which was reverted upstream for non-technical reasons. Requires anyio >= 4.5.0. ref
Retire map_exceptions() context manager in favour of plain try/except on hot paths (socket reads, writes, connects). try/except with no exception is nearly free; @contextmanager-based with blocks have measurable overhead. (encode/httpcore#1044) PR 14
Make Origin hashable via Origin.__hash__() for use in sets and dicts. (encode/httpcore#1038)
Release the HTTP/2 max-streams semaphore and decrement _concurrent_streams when NoAvailableStreamIDError is raised, preventing permanent deadlock. (encode/httpcore#1061) PR 10
Move del self._events[stream_id] inside the _state_lock in _response_closed() to prevent a race condition with concurrent coroutines. (encode/httpcore#1062)
Close proxy connection when tunnel TLS handshake fails, preventing the pool from stalling at max_connections. (encode/httpcore#1049)
Propagate the connect timeout through the SOCKS5 handshake to prevent indefinite hangs with non-responsive proxies. (encode/httpcore#1055) ref
Explicitly close async generators via safe_async_iterate() context managers to prevent Trio warnings and unpredictable GC-dependent behaviour. (encode/httpcore#1019) ref
Reduce lock contention in PoolByteStream.close(): pool requests are marked as closed outside the lock and cleaned up lazily inside _assign_requests_to_connections(). (encode/httpcore#1038) ref

These are serious issues, and it’s not even all. Almost all of these were already fixed by ‘the community’ and were living in unmerged pull requests. We code reviewed them, fixed them up where needed and adapted them to our code base. We also now added a benchmarks section to the documentation; httpxyz is now MUCH faster than httpx in many serious use cases.

Then we released a new version of HTTPXYZ earlier this week: 0.31.0 with this updated version of httpcorexyz and also more bug fixes of its own.

Where I previously stated having the fork is about future-proofing and I would not necessarily recommend people to switch to httpx, with this new version 0.31.0 I now feel that you should definitely move to httpxyz. With All new fixes and performance improvements it now makes ‘business sense’ to switch from httpx to httpxyz, the ‘churn’ is worth it now!

Adoption

We’re happy to see projects moving to using our package, even though it’s not much yet. We encourage everyone to do so, and please tell others and convince them! If you would find issues with your switchover, which I do not expect, please just open an issue and I’m sure we can figure it out!

Quotes

I'm a big user of httpx... Thanks for the fork. Here's to hoping it gained some traction. (Michael Kennedy, Founder, Talk Python)

Thank you for forking httpx. httpx is a joy to work with, but clearly a bit dead in the water. Really nice to see it moving forward again. (hhartzer)

If you want to have traction, you should probably move to GitHub instead of using Codeberg (Marcelo Trylesinski aka Kludex / FastAPI)

On Codeberg

We explained the last time why we chose Codeberg; we’re not unhappy about our choice. We got 39 ‘stars’ so far on our Codeberg repository and many of those are from ‘fresh’ accounts. If us being on codeberg helps a tiny little bit making github a bit less dominant, I think this is a good thing, and I hope it can inspire other projects to do the same. And after all, for most users, who would just pip install httpxyz or uv add httpxyz it does not matter where the source is hosted.

Thanks, and have fun!

Talk at PyAmsterdam on httpxyz

2026-04-21T22:00:00+02:00

On Wednesday 29th of April 2026 I will be giving a lightning talk on our new fork of the popular python package httpx called httpxyz at PyAmsterdam. httpx is a top-100 Python package for sending http requests but has not had a release since end of 2024, plus, recently all issues were set to hidden and all discussions are closed. httpxyz is our friendly fork with lots of fixes for serious and more niche issues. Read for more info my announcement post for httpxyz. I will talk about why we did the fork and how we approach it. The event is fully booked and there is a wait list.

As the organizer of Python Leiden, I am happy to be checking out another Python meetup group.

Plus, I’m excited to be giving a talk on HTTPXYZ; my first blog post about it got a lot of views on Hacker News but not (yet) so much adoption in real life, and we definitely need to “spread the word” more.

I look forward to giving my talk & see you there!

Check the details for the Meetup.com event

Why I forked httpx

2026-03-25T22:00:00+01:00

Yesterday I forked httpx. The new fork is called httpxyz.

Reasons for the fork

HTTPX is a very popular HTTP client for Python. There is lots of code depending on it.

In 2024, I contributed zstd content decoding. This got merged and released! I was very happy and proud. Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024. Me, and others, asked repeatedly for a release containing my fix. I sent email to the author personally. I got response when I added that I was considering forking. The author replied “1.0 development is on course”. Which is probably true but it has been in the planning for over two years now ref. Even the ‘patch level’ release for 0.28.2 has been in draft for over a year.

And apart from this, there’s:

Recently issues have been made hidden on the github repository, and discussions have been turned off. Having issues hidden makes it more difficult for people to contribute to the package but also to use the package since issues are linked all over in code and documentation also. See reddit thread
There has been talk about an upcoming 1.0 release for years now, back to 2020 or so. In a discussion from October 2024, it was laid out that the 1.0 might look very different than the current version of httpx. Simon Willison added his points eloquently, please read them.
Probably as a result, both openai and anthropic python packages, that depend on httpx, have put guards in their pyproject.toml to not install version 1.0.
The author previously added breaking changes in minor updates, causing churn for many people, stating “The httpx package is not yet at a 1.0 SEMVER release” ref. It’s pre-1.0, that is right, but if so many people use your package a bit more consideration for compatibility seems in place.
The author also created Django REST framework, and turned off issues and discussions there, a little over a year ago. This made life for people using the product more difficult ref
The author also created MkDocs, of which an interesting blog post was published recently. Some patterns seem to be recurring.

All this together made me think creating a fork is the best way forward, to provide a stable path for people invested in httpx.

I do understand about maintainer burnout, and preferring to work on ‘next’, and that there is life outside of Python, but I think not doing anything for maintenance and also not letting other people help out in maintaining, for such a high profile module, is problematic.

I do hope that Kim will go on to make much more beautiful software and that there will be a HTTPX2 that will be excellent!

FAQ

Q: Why did you fork?

See all the reasons above

Q: So what is the plan now?

Maintain a stable fork of httpx. No great rewrites, no breaking changes, no big changes to the project setup (for now). The motto is: Move a little faster and not break things.

Q: But are you not also going to burn out? Surely it’s lots of work

There has been no release since 2024 for httpx. A little more frequent would go a long way. My buddy Sander Wegter is a co-maintainer to spread the load.

Q: Why is your code on Codeberg and not on Github?

I feel that as a tech community we have put too many eggs in one basket. GitHub has been great for developers over the years, but I’m worried about the monoculture. Codeberg is still a little “rough” but for most intents and purposes, it just works. You can see the repository here. Codeberg is run as a non-profit instead of by a megacorp. Plus, I spoke with a bunch of them on FOSDEM this year and they’re very nice people.

Q: Should I port all my code now?

If you want, you’d be welcome. But if everything just works for you now, I’m not sure it’s warranted. The idea is that there is a path for you if you need it. That said, we’re fixing lots of bugs. UPDATE: with our new fixes we changed this position; httpxyz is much faster now than httpx and has much less bugs, we encourage everyone to upgrade! ref: httpxyz one month in

Q: but what about plugins?

If you’d use import httpxyz as httpx, many things will just work. And for packages that itself depend on httpx, if you import httpxyz before you load that package, you’ll use our new package instead. See httpx compatibility I think that with the 0.3.0 release we’ve covered all bases, if you still have problems, please just open an issue and I’m sure we can figure it out!

Thanks, and have fun!

Discussion on Hacker News here

Talk at Leiden Software Meetup on finger

2026-03-11T22:00:00+01:00

On Thursday 19th of March 2026 I will give a lightning talk on the humbe “finger” protocol, its history and my re-implementation in Python & SystemD at Leiden.dev, the Leiden Software meetup. This is a monthly meeting in Café de Keyzer which is held at every third Thursday of the month. In a cozy setting you can talk with other software people and enjoy talks on different subjects.

I look forward to giving my talk & see you there!

65 lines of Markdown - a Claude Code sensation

2026-02-12T08:00:00+01:00

Yesterday my employer organized an AI workshop. My company works a lot with AI supported code editing; using Cursor and VS Code, GitHub Copilot. Plus we do custom stuff using AWS Bedrock, agents using Strands and so on, all the stuff everyone is working with nowadays.

Our facilitator explained how custom rules files can be so very helpful for AI tooling. He linked to this extension with Karpathy-Inspired Claude Code Guidelines as an example. Apparently this plugin is very popular! Yesterday morning the project had 3.5K stars and at the end of the day this already increased to 3.9K. That’s a lot of stars.

I went on to investigate what this extension actually does and found that it’s just one Markdown file of 65 lines long that lays out four principles; the first one is “Think Before Coding”, added with some packaging to make it install in Claude Code.

Publishing it as a Cursor extension

But I don’t use Claude Code, so I fired up Codex CLI and turned it into an extension for VS Code and for Cursor, which is a fork of VS Code but uses a plugin registry from the Eclipse Foundation.

Getting the plugins published was the most work. On the ‘VS Code Marketplace’ I am not a Verified Publisher meaning I do not get a green check mark next to my name, and you will get a warning if you want to install my extension. And apparently the only way to get rid of that is to wait for six months with at least one extension published and then apply for verification. So starting August I can apply for that and any new extensions get automatically trusted.

For Cursor the process felt very cumbersome: I had to create an account on open-vsx.org, create an Eclipse Foundation account, link those accounts, link to my GitHub account, sign an Eclipse agreement, and finally create a GitHub Issue to ‘claim’ my VS Code Marketplace namespace.

Using the extension

So, what does using the extension actually feel like? Because of the non-deterministic nature of these models, I found it hard to tell. I tried a simple refactoring, and I had the idea that it was very reluctant in making changes. Was the result better? I’m not really sure.

Typically, your Cursor rules would list the constraints for your environment, explaining what coding standards to adhere to, architectural constraints and so on. I get that, it makes sense.

I find it wild to think that a company spends millions and millions of dollars on training a model, with tons of engineers meticulously improving output, and then some guy comes along and writes 60 lines of text including Think before coding in the rules and that would make all the difference.

But the original repository has almost 4,000 stars, and surely, 4,000 developers can’t be wrong?

Please try for yourself! Install the extension, don’t forget to star my repository and see the results.

As Paul Simon wrote: These are the days of miracle and wonder!

Discussion on Hacker News

My issues with ProtonMail

2026-02-05T21:21:00+01:00

I use my own domain for email, which I’d recommend to everyone. I was on a cheap Hetzner ‘web hosting with email’ plan before, which wasn’t ideal. During last November’s Black Friday sales I got a ProtonMail subscription and moved my domain there. But I’ve run into several issues, some with how their product works, others specific to my setup.

Can not open some mails on mobile

A small percentage of emails simply won’t open on iOS. When I tap them, the app briefly shows the subject, then closes. I can’t read the content. These same emails work fine in the web interface.

This is a serious problem: your mail client should be able to read mail! I haven’t been burned yet, but I worry about the day I need to show a boarding pass or concert ticket at the door and can’t open it.

I realized there is a workaround for this: opening the web interface in my mobile browser, but that’s far from ideal. ProtonMail has confirmed the issue and says they’re working on a fix.

Mail spoof warning does not show in mobile app

My employer recently switched payroll providers. ProtonMail warns that their mail server isn’t properly configured and the messages could be spoofed, yet coworkers on Gmail or Outlook see no such warning. After checking with our security officer, we concluded the mails are valid and ProtonMail is being overly cautious.

The strange part: this warning only appears in the web interface, not the iOS app, or on the Android app.

If there were an actual spoofing attempt, I’d want to know, especially on mobile! I’ve raised this issue with Proton support.

Mail read flags do not seem to sync between mobile and desktop

Emails I’ve read on my phone sometimes show up as unread in webmail later. Others on Reddit report the same thing, and Proton has confirmed they’re investigating. This is table-stakes stuff for a mail client.

Pulsating menu in ProtonMail

When I open the context menu in a message, it ‘pulsates’. A minor issue, but it’s been there for over two months, testament to the lack of polish in their apps. This only happens on iOS; a co-worker on Android doesn’t see it.

No third party mobile clients

ProtonMail encrypts all data at rest and decrypts on your device. Nice in theory, but it means no standard IMAP, so you can’t use your favorite mail client directly.

The workaround is installing the ProtonMail Bridge on your laptop, which decrypts locally and exposes IMAP for Thunderbird, Outlook, etc. But this doesn’t work on mobile. There you’re stuck with their app or the web interface.

I use Linux with ProtonMail in a browser tab; I don’t love the Bridge approach.

No instant search in webmail without local indexing

Another consequence of client-side decryption: search doesn’t just work. For full-text search, your browser has to download and index all your mail locally. This takes a long time initially.

Conclusion

I really want to love ProtonMail. They’re steward-owned, privacy-focused, European, and building out a full suite of products (VPN, calendar, etc.). But their core product is email, and it has too many rough edges. I expected better from a company that’s been around this long and is this popular. I’ll be migrating elsewhere soon.

That said, most of my issues are with the iOS app. Android users likely have a better experience.

Reinout van Rees on prefect.io

2026-01-22T21:00:00+01:00

Reinout is a long-time visitor of the Python Leiden meetup. In fact, he is a regular on most nearby Python meetups and conferences. The nice thing is that he also writes summaries of the talks he attends and he publishes those on his blog. I really appreciate this! Today he gave a talk at our meetup, and I decided to ‘return the favour’ so here is my summary of his talk!

Reinout discusses prefect.io: it is a server that provides a dashboard, has an API, shows workflows, and allows you to start/restart jobs, examine logs, and such.

In his company much IT-related work involves loading data from web APIs, transforming it in some form, loading it in databases and so on.

Previously this was all done on the command line and people had to log in over SSH and there were constraints about rotating ssh keys which all made it very cumbersome. Now they have a nice web UI and not so much IT restraints and it’s much easier for people because they can just log in to a web UI and click around.

In Prefect, workflows are defined. Workflows consists of one or more tasks. Those tasks are written in python. Prefect comes with some niceties to configure retries on your tasks, it provides a custom logging framework and a lot more. In the UI you can manually start jobs, configure workers, and monitor progress.

Prefect does not provide its own authentication mechanism at the moment. So if you want to ‘protect’ it people are using HTTP Basic auth.

It comes with a docker setup, which is what Reinout is using. Also a hosted version is available.

Reinout created a cookiecutter template that allows non-programmers to create simple python tasks. This has built in workflow that creates a github repository, and configures github actions that creates docker containers on every commit on main, and pushes those to a docker registry.

He uses ‘watchtower’ in the docker compose setup, which allows him to simply deploy the stack once, and the stack will poll for updated containers and keep itself up to date.

I think it’s nice to see that they are able to provide a frictionless way to set up, deploy and monitor data jobs for people who are more data-minded and not hardcore sofware developers!

JPEG XL Test Page

2026-01-21T17:30:00+01:00

This page shows a JPEG XL image, if your browser can handle it! At this point in time (January 2026) this more or less means only Safari will display the image, as far as I know. See also Can I Use.

The person in the image is Jon Sneyers, co-author of the JPEG XL spec and also creator of the “Free Lossless Image Format” that came before it.

I find JPEG XL interesting because of its history. It once was implemented in Chrome, but hidden behind a feature flag. Then Chrome said that it did not saw enough usage, which is unsurprising, really, and it was removed. Now they blessed it again and are re-adding it! Some of this story is found on the JPEG XL Wikipedia page