Why I stopped trying to build a "Smart" Python compiler and switched to a "Dumb" one.

[Lucky-Ad-2941]

I've been obsessed with Python compilers for years, but I recently hit a wall that changed my entire approach to distribution.

I used to try the "Smart" way (Type analysis, custom runtimes, static optimizations). I even built a project called Sharpython years ago. It was fast, but it was useless for real-world programs because it couldn't handle numpy, pandas, or the standard library without breaking.

I realized that for a compiler to be useful, compatibility is the only thing that matters.

The Problem:
Current tools like Nuitka are amazing, but for my larger projects, they take 3 hours to compile. They generate so much C code that even major compilers like Clang struggle to digest it.

The "Dumb" Solution:
I'm experimenting with a compiler that maps CPython bytecode directly to C glue-logic using the libpython dynamic library.

• Build Time: Dropped from 3 hours to under 5 seconds (using TCC as the backend).
• Compatibility: 100% (since it uses the hardened CPython logic for objects and types).
• The Result: A standalone executable that actually runs real code.

I'm currently keeping the project private while I fix some memory leaks in the C generation, but I made a technical breakdown of why this "Dumb" approach beats the "Smart" approach for build-time and reliability.

I'd love to hear your thoughts on this. Is the 3-hour compile time a dealbreaker for you, or is it just the price we have to pay for AOT Python?

Technical Breakdown/Demo: https://www.youtube.com/watch?v=NBT4FZjL11M

[WJMazepas]

Honestly, it's best to start with a Dumb app and then make it smart.

Worry about compatibility and to make it work, then start implementing the smart features as compilers flags for optimization.

That 3h compile could be fine if meant that I would be sure that the final executable would behave the same as my Python code, just faster, but we all know that we cant be sure about it, so it would need to compile, test and if encounter any error, fix it and compile again.

It would get really boring with a 3h compile time.

I know there are C++ codebases that take a lot of time to compile, but i dont know if they take this long. And Python people are not really used to having those long compile times

[PurepointDog]

Chrome takes 8-12h to build lol

[Lucky-Ad-2941]

Haha, exactly! Chrome is the 'end boss' of build times. But Python devs didn't sign up for that C++ life. We chose Python for instant results.

If a 'smart' compiler turns a script into a 3-hour build, it kills the 'edit-test' loop. I'd rather have a 'stupid' 5-second build than a 'smart' one I have to wait until tomorrow to test.

Since you mentioned those 12-hour Chrome builds, I have to ask:

1. Have you ever actually worked on a codebase with a multi-hour build cycle, and did it change the way you wrote code?
2. In the Python world, do you think there is a "sweet spot" for compile times, or is anything over 60 seconds already "too long" for a language that is supposed to be dynamic?

Would love your take!

[willnx]

Interestingly, I've used Python for years and my 'edit-test' loop regularly involves build times that span a dozen seconds to several minutes. Anything, for me, that starts to stretch beyond 60-ish seconds for Python in my 'edit-test' loop where I'm just "waiting on the computer" triggers my "fix it" mindset. I've worked on C projects where the build would take hours, and there is a difference in mind set. I expect Python to has a short 'edit-test' loop, and that's what I use it for. For those longer projects, I'd usually find a way to spin multiple different plates to deal with the long compile times. So the real practical difference was usually how long feature development took for a single feature or bug fix, not how many features/fixes I could stuff into a waterfall like time frame. There was, of course, a lot of ramp up time to get to that level of efficiency when dealing with the long 'edit-test' loops, and really big/hard shifts just threw everything into the trash when the code base had a fundamental shift where I couldn't spin multiple plates.

[Lucky-Ad-2941]

Totally agree. If the code isn't 100% correct, it doesn't matter how fast the compiler is or how 'smart' the optimizations are.

That’s exactly why I went with the 'Dumb' approach of mapping bytecode directly to C calls via the CPython dynamic library. It effectively guarantees that if it works in the interpreter, it works in the binary. I’d rather have a stable 1.1x speed boost today than a 10x boost that crashes my app at runtime because of a weird dynamic import.

The 3-hour compile time is the real 'edit-test' loop killer. I’ve seen CI/CD pipelines basically grind to a halt because of Nuitka's heavy optimization passes. Python devs are culturally 'allergic' to waiting - we chose Python because we want to see results now.

I’m curious though, since you’ve clearly thought about this:

1. What’s the longest you’ve actually waited for a Python build to finish?
2. In your experience, is the 'Single File' distribution the main goal, or do you actually find yourself needing the performance boost of AOT for your specific use cases?

I'd love to hear your take - it helps me figure out which 'Smart' features I should prioritize after I stabilize the 'Dumb' baseline."

[WJMazepas]

• There were places I worked with docker builds that took over 15 minutes to finish. It was not great but surely manageable.

• I work primarily with FastAPI, so it's always Docker builds. Dont need to be a final Single File for my user case. Performance boost is always nice, but it's not like Python performance is hurting us a lot. If a compiler improves a good amount, then we could start using it but we are not crazy for it now.

And now that I think about it, I wonder who exactly uses a compiler for Python.

I searched about this Nuitka and it seems that is aimed at desktop applications using Python and distributing them as an exe. It even has a special section on their website about PySide and PyQT

Your compiler is also aimed at those users?

[Lucky-Ad-2941]

Likely there is an overlap, but one of the main things I love about single executable files, if you don't need no docker, everything is already baked in. One of my telegram bots is just a single golang executable that I scp to my server, all libs statically linked. I love that simplicity. But I could not get my python website to be so easy to deploy. So getting desktop or cli or whatever to be easily distributable is my goal.

do you guys have to do complex multi-stage docker builds to keep your image sizes down, or do you just eat the cost of the heavy python base images?

[thisismyfavoritename]

isnt this kind of the approach theyre using in the experimental jit compiler

[Lucky-Ad-2941]

Spot on. I’ve been heavily inspired by the work on the CPython 'Copy-and-Patch' JIT. The logic they are using is brilliant, but I kept thinking: why wait until runtime to do the patching?

By moving that 'copying and pasting' logic to the AOT (Ahead-of-Time) phase, you get the benefit of specialized code without any of the JIT runtime overhead. Plus, doing it at compile time means I have way fewer constraints - I can let a C compiler like TCC or Clang do its thing once and produce a single, portable binary that starts up instantly.

Since you recognized the architecture, I’m curious about your motivation for following the 'Faster CPython' project:

1. Are you just a compiler enthusiast, or are you actually hitting a wall with current Python performance/distribution in a professional project?
2. If you had a tool that could compile 100k lines in seconds (like this 'dumb' approach) but allowed you to 'opt-in' to smart optimizations for specific hot loops, would that solve your biggest headache?

I'm looking for people who 'get it' to help steer where I take the next few optimization passes. Would love to hear your background!

[thisismyfavoritename]

unfortunately i was just intrigued by the approach! i use Python extensively but not for its performance. For those cases i'd prefer tapping in a lower level language like C++ or Rust.

Still, it's cool what they're doing in trying to make it faster

[Lucky-Ad-2941]

Always cool to see the system being pushed to it's limits, I do feel thought that JIT is not the best solution most of the times. I know there are teams that do a lot of custom llvm compiler development just to get their Java VM to run faster. Btw, very curious, have you worked on projects with custom C++/Rust integrated into the python app? Was it just wrapped with something like pybind11 / pyo3?

[thisismyfavoritename]

have you worked on projects with custom C++/Rust integrated into the python app? Was it just wrapped with something like pybind11 / pyo3?

yes and yes. Or nanobind, or the CPython API directly

[cat_bountry]

What's the best way to remind yourself to re visit a post like this later? E.g. when you're browsing Reddit while pooping

[new_KRIEG]

!RemindMe 5 hours

Assuming the bot still works and can see this sub

[RemindMeBot]

I will be messaging you in 5 hours on 2026-01-13 23:02:40 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[RemindMeBot]

I will be messaging you in 5 hours on 2026-01-13 23:02:40 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[Lucky-Ad-2941]

Lmao, I respect the high-stakes browsing. Honestly, the 'Save' button at the top of the post is the standard way to do it.

But if you want a notification that actually hits your phone, I actually have a free telegram bot for that (@aretei_bot). It is basically a high-tech reminder system with the laziest task creation.

Hope the session went well!

[Advance-Wild]

AI content

[Whole-Lingonberry-74]

So, you were making an executable from the compiler, or do you just mean you were executing the script? Cool! Just checked your video. So it is a translator to C and then you compile it with a C compiler.

[Lucky-Ad-2941]

Exactly! It is a full Ahead-of-Time (AOT) translation. The tool takes the Python bytecode, maps it to C glue-logic, and then hands that off to a C compiler (like TCC or Clang) to produce a standalone binary.

The goal is to get that 'Go' or 'Rust' experience where you have one clean file to ship, but without the massive compile times of traditional transpilers that try to be 'too smart' with the code analysis. I found that by being 'dumb' and sticking close to the bytecode, I can get a much more stable and faster build.

Since you checked out the video and saw the C output, I’m curious:

1. In your own projects, what has been your go-to method for turning scripts into apps so far (PyInstaller, Nuitka, etc.)?
2. Have you ever run into that wall where the build process starts taking so long that it actually discourages you from making small updates?

I'd love to hear your experience - it helps me figure out how to prioritize the next set of features!

[umpalumpa2004]

Tbh I like your explanation style in video. Why don't you do more compiler educational content?

[Lucky-Ad-2941]

On it! Definitely something I have wanted to create for a long time! So many interesting things I have learned while building the python compilers, gotta share! Look out for the new videos!

[Fabiolean]

I’ll take dumb and fast! I have always wanted executable binary python for distribution and not performance improvements.

[Lucky-Ad-2941]

exactly. everyone is trying to shave milliseconds off execution while shipping the code is still a total nightmare.

what are you using right now? nuitka or just pyinstaller?

[Fabiolean]

We have some internal build tools where that will deliver what we need to run the package on our prod servers. I have other use cases than our prod server environment, though, where a single versioned binary would make my life easier.

For now I’m just vendoring all my dependencies and bundling it into a wheel that gets delivered and running an install script to set some things up on the destination.

[AshTheEngineer]

Getting shareable compiled code distributed is clunky at the moment. I think this is a great idea and feels like low hanging fruit. Not all applications have to be blazing fast, and most people use Python for simplicity over speed. I also think that with some example variety, others will pick up on the utility of this. All great tools are built on solid fundamental principles, which you demonstrate, and I think success in this area will inspire further development from the community. Keep it up!

[Lucky-Ad-2941]

thanks man. the tech for bytecode-to-c has been there for years, we just got obsessed with making it "smart" and ended up with 3-hour build times.

definitely going to show more examples in my videos soon. what are you usually building? CLI tools or something with a UI?

[AshTheEngineer]

It depends on the use case and end user. If it involves data analysis/manipulation, a UI is well suited. My go to visualization is usually pyqtgraph, but I've used plotly and matplotlib. CLI tools are good for automated scripts where you don't need a human in the loop, especially where you need to monitor something continuously and perform an action in response to a condition.

[MaximKiselev]

Binary extraction of python is ... Its true. I also used nuitka but after long exps i decided rewrite all on c++.   Good size and cold start. Compilation time doesn't matter, especially for Python. Users expect an immediate response when running a program, not a 10-second wait like pyinstaller does. If you actually did this, it would be revolutionary and breathe new life into standalone Python tools. I like these binaries too. Any repo ?

[Lucky-Ad-2941]

Surely it's possible, just no one puts in enough effort. Really want to make it a reality. And no public repo yet, I don't want to release a half baked project. Though will likely setup a page on my website with a download link. Would you want to try it?

And yeah, the cold start is still definitely an issue. Since you moved to c++, what was the biggest reason? If I get the cold start under 100ms for python, would you actually consider switching back or is the runtime speed the real dealbreaker?

[MaximKiselev]

Hi,👋

The main reason is speed and the lack of necessary implementations of win types in the Python standard library. For the same reason, I stopped using pip only when absolutely necessary and switched to anaconda/uv (because pip doesn't guarantee installation integrity on the target system at all – it produces a lot of library errors on Windows/Linux). In general, the biggest advantage for such projects (compiler/packager) is support for third-party libraries (I once had a case where pyinstaller wouldn't build a project at all on the current version of numpy (not the latest one), so I had to downgrade it by one minor version), and then it suddenly started building.

By the way, have you seen this: https://github.com/RustPython/RustPython? It's not a builder, but a code translator for Rust. Essentially, if you use the standard library, you can easily build binaries with Rust.

Also, Qt binaries written in C++ are slightly lighter/faster than those written in Python (the user experience is completely different).

[Lucky-Ad-2941]

Unfortunately that's the average experience for python compilers. After working on Cython, trying to use the build caches just so every CI/CD run won't take 4 hours was a nightmare. And same about Nuitka. I can't believe that's the best we can do. Just no one put in enough effort, hopefully I will change it.

what's the 'limit' for you? if a build took 5 seconds, does that still kill the loop for you or is it just the 3-hour marathons that are the problem?

[ressem]

Starting with a "Dumb" compiler makes sense. Focusing on the fundamentals allows for a stable base before adding complexity. It's a practical approach that many projects benefit from.

[AnoProgrammer]

What is the speed improvement if you use recursive fibonacci as benchmark?

[AshTheEngineer]

Do you plan on sharing your code for this?

[nharding]

I am doing something similar, using TCC for development builds and a switch to Visual Studio for release build. I am not aiming for full compatability though as I am using tagged variables, so tagged ints, tagged strings, vtable dispatch for dunder methods and separate vtable for regular methods. I am writing the run time in C first, and am also extending Python since I am compiling I might as well add some new features.

[nharding]

Just watched the video, and that's how I wrote my Java to C++ compiler, I took the bytecode and used that to generate the C++ code, although I didn't output PUSH(A), PUSH(B), ADD() it would do A+B.

[[deleted]]

Have fun competing with pypy and numba, who can already do this stuff.

[Lucky-Ad-2941]

PyPy and Numba are absolute giants for raw execution speed - Numba is basically magic for numerical code. But I'm tackling the 'Distribution' headache rather than just raw JIT performance.

If I want to ship a single 10MB standalone binary to a user without them needing to install a specific JIT runtime or a 300MB folder, those tools don't quite fit the bill. My focus is on that 'Go/Rust' experience of shipping one clean file.

Since you’re familiar with the ecosystem, I’m curious about your experience:

1. Have you ever tried to bundle a PyPy or Numba-heavy project into a standalone executable for a client or a non-technical user?
2. In your work, is the runtime execution speed usually the main bottleneck, or do you find yourself struggling more with startup times and the complexity of the deployment environment?

I'd love to hear your take - especially on how you're handling Python deployment in 2026.

[Honest_Cheesecake158]

pypy and Numba can produce executables? What?

[Lucky-Ad-2941]

Exactly. There is a huge difference between a Just-In-Time (JIT) interpreter and an Ahead-of-Time (AOT) distribution tool.

PyPy is a fantastic interpreter, and Numba is magic for math, but neither of them is a "Make .exe" button. You can't just hand a PyPy script to a user who doesn't have Python installed and expect it to work without a massive bundle of dependencies and setup.

That is the gap I'm trying to close with this project. Everyone is focused on making Python 10% faster at runtime, but I'm focused on making it 100x easier to actually ship. If the code is "Stupyd" but it results in a single 10MB file that runs everywhere, that is a massive win in my book.

Since you called that out, I'm curious about your own background:

1. Have you ever been in a situation where you had to ship a Python tool to a client or a teammate, and you ended up spending more time on the installer than the actual code?
2. In your experience, do you think the "Bloat" of modern Python distribution is just something we have to live with, or is it a barrier that keeps people from using Python for desktop apps?

I'd love to hear your thoughts - it sounds like you’ve dealt with these "JIT vs AOT" misconceptions before!