It would be better for Python to support AOT compile officially

I am very happy to hear that Python now supports JIT(Just In Time) compile feature!

Although it makes Python program run much faster than now, still some problems remain.

One is that we still need Python to be installed at end-users’ computers. Another one is that the program will be still slow at the starting moment.

Supporting AOT compile is the key to solve both problems above.

Moving this to help as it is not formulated as a proposal that will actually get constructive work towards the idea in motion. Additionally, there are already projects that compile python to executables.

One is that we still need Python to be installed at end-users’ computers. Another one is that the program will be still slow at the starting moment.

Supporting AOT compile is the key to solve both problems above.

I both fail to grasp your point and fail to conceive of any way forward that doesn’t require huge refactoring of the entire CPython codebase, and numerous breaking changes for millions of users.

AOT is fantastic for those that need it, those who opt-in (e.g. Numba users, or those considering Mojo).

I’m not sold on the benefits of breaking such a well established language, even one not as established as Python, e.g. for all those millions of usrs who only need to Automate The Boring Stuff.

Whereas on the other hand, instead of breaking an entire dynamic, language, those of you that want an AOT static binary or ‘executable’ can simply pick one of any number of alternative tools.

That said, I’m all ears. But you will need to make an exceptional, ground-breaking case.

1 Like