Python 3.13's new JIT and no-GIL modes

[@sdmagic]

Very nicely done.

[@OmarHashimOAD]

I enjoy your content; keep up the great work!

[@rafael86ny]

Wonderful content!

[@felixfourcolor]

I believe Fedora 41 will ship Python with the JIT, but disabled by default (can be turned on via command line argument). I don't think any distro will ship free-threading though.

[@InfoWorld]

That's useful to know. 3.13 beta 2 is shipping with an experimental version of free-threading enabled for Mac users during the installation process, but so far that's the only precompiled version being shipped by Python.org right now. For the time being the rest of us will have to compiled it by hand. -Serdar

[@alexandermorgan5869]

Great video! Are there any instructions on how to build these two different versions of python 3.13?

[@InfoWorld]

I actually have plans for a future video where I demonstrate the compilation process on Windows! Stay tuned. -Serdar

[@timmurphy5541]

multiprocessing has advantages because a crash in one process cannot affect the other. Perhaps we're not accustomed to crashes in python but I don't think it's impossible when you're using C modules. Personally I think it's also imaginable that we could turn it into a multi-computer mechanism without any structural change.

[@teawithoutdonuts31]

The question I eant answered is how will this affect ASGI and WSGI web frameworks.

[@benshapiro9731]

My best guess based on experience with FastAPI: the way fast api runs its route handler funcs is if the func is a coroutine (async def) and thus can pause execution during await calls, then it is run on the main thread. If it is a blocking function (def) then it is delegated to the underlying threadpoolexecutor via something like asyncio.to-thread. In my experience, a lot of production code uses just normal functions as opposed to Coroutines for the route handlers due to the relatively recent introduction of async mechanics into the language. If running the no Gil python really has no effect on single threaded code, then at worst this change will have no effect and at best it will give asgi frameworks that work similarly to fastapi a huge speed boost (since those blocking route handler funcs can be executed truly in parallel via the thread pool executor). As far as I know the current best practice is to put non blocking io into async functions and cpu bound tasks into regular functions. Even though Asyncio event loop executes coroutines on the same thread as the event loop, the fact that coroutines are a much lower cost abstraction than threads means that this execution model is faster than using a thread pool. However, the removal of the Gil could change that if the numbers and benchmarks start telling a different story. This may necessitate some internal changes to various asgi frameworks to delegate more coroutines to thread pools as opposed to running them on the main thread. But if your route handler funcs are just regular functions, then out of the box this should yield a major speed increase.

[@jaimel8219]

The culprit will be the 3rd party libraries partially unmaintained that most web apps depend on. GIL enabled tons of thread-unsafe code to be written.