21 Nov 2025 4 min read Python

I want to be upfront that this blog post is for me to write down some thoughts that I have on the idea of rewriting the Python Launcher for Unix from Rust to pure Python. This blog post is not meant to explicitly be educational or enlightening for others, but I figured if I was going to write this down I might as well just toss it online in case someone happens to find it interesting. Anyway, with that caveat out of the way...

I started working on the Python Launcher for Unix in May 2018. At the time I used it as my Rust starter project and I figured distributing it would be easiest as a single binary since if I wrote it in Python how do you bootstrap yourself in launching Python with Python? But in the intervening 7.5 years, a few things have happened:

• BeeWare’s Briefcase has grown in sophistication
• Python-build-standalone has helped show that Python can be rebuilt in a relocatable way for easy distribution
• I have started the work to get relocatable, prebuilt binaries hosted on python.org
• I have plans for the Python Launcher for Unix (a normal person might say “big” plans, but I think people now realize my “normal” isn’t normal 😅)
• I became a dad (that will make more sense as to why that matters later in this post)

All of this has come together for me to realize now is the time to reevaluate whether I want to stick with Rust or pivot to using pure Python.

Performance

The first question I need to answer for myself is whether performance is good enough to switch. My hypothesis is that the Python Launcher for Unix is mostly I/O-bound (specifically around file system access), and so using Python wouldn’t be a hindrance. To test this, I re-implemented enough of the Python Launcher for Unix in pure Python to make py --version work:

• $VIRTUAL_ENV environment variable support
• Detection of .venv in the current or parent directories
• Searching $PATH for the newest version of Python

It only took 72 lines, so it was a quick hack. I compared the Rust version to the Python version on my machine running Fedora 43 by running hyperfine"py --version". If I give Rust an optimistic number by picking its average lower-bound and Python a handicap of picking its average upper-bound, we get:

• 3 ms for Rust (333 Hz)
• 33 ms for Python (30 Hz)

So 11x slower for Python. But when the absolute performance is fast enough to let you run the Python Launcher for Unix over 30 times a second, does it actually matter? And you’re not about to run the Python Launcher for Unix in some tight loop or even in production (as it’s a developer tool), so I don’t think that worst-case performance number (on my machine) makes performance a concern in making my decision.

Distribution

Right now, you can get the Python Launcher for Unix via:

1. crates.io
2. GitHub Releases as tarballs of a single binary, manpage, license file, readme, and Fish shell completions
3. Various package managers (e.g. Homebrew, Fedora, and Nix)

If I rewrote the Python Launcher for Unix in Python, could I get equivalent distribution channels? Substituting crates.io for PyPI makes that one easy. The various package managers also know how to package Python applications already, so they would take care of the bootstrapping problem of getting Python your machine to run the Python Launcher for Unix.

So that leaves what I distribute myself via GitHub Releases. After lamenting on Mastodon that I wished there was an easy, turn-key solution to getting pure Python code and bundling it with a prebuilt Python binary, the conversation made me realized that Briefcase should actually get me what I’m after.

Add in the fact that I’m working towards prebuilt binaries for python.org and it wouldn’t even necessarily be an impediment if the Python Launcher for Unix were ever to be distributed via python.org as well. I could imagine some shell script to download Python and then use it to run a Python script to get the Python Launcher for Unix installed on one’s machine (if relative paths for shebangs were relative to the script being executed then I could see just shipping an internal copy of Python with the Python Launcher for Unix, but a quick search online suggests such relative paths are relative to the working directory). So I don’t see using Python as being a detriment to distribution.

Maximizing the impact of my time

I am a dad to a toddler. That means my spare time is negligible and restricted to nap time (which is shrinking), or in the evening (which I can’t code past 21:00, else I have really wonky dreams or I simply can’t fall asleep due to my brain not shutting off). Now I know I should eventually get some spare time back, but that’s currently measured in years according to other parents, and so this time restriction to work on this fun project is not about to improve in the near to mid-future.

This has led me, as of late, to look at how best to use my spare time. I could continue to grow my Rust experience while solving problems, or I could lean into my Python experience and solve more problems in the same amount of time. This somewhat matters if I decide that increasing the functionality of the Python Launcher for Unix is the more fun for me than getting more Rust experience at this current point of my life.

And if I think the feature set is the most important, then doing it in Python has a greater chance of getting external contribution from the Python Launcher for Unix’s user base. Compare that to now where there have been 11 human contributors over the project’s entire lifetime.

Conclusion?

So have I talked myself into rewriting the Python Launcher for Unix into Python?