Programming

16977 readers

156 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

GIL Become Optional in Python 3.13 (geekpython.in)

submitted 1 month ago by pnutzh4x0r@lemmy.ndlug.org to c/programming@programming.dev

6 comments fedilink hide all child comments

cross-posted from: https://lemmy.ndlug.org/post/970135

GIL or Global Interpreter Lock can be disabled in Python version 3.13. This is currently experimental.

Python 3.13 brings major new features compared to Python 3.12 and one of them is free-threaded mode, which disables the Global Interpreter Lock, allowing threads to run more concurrently.

The GIL will be disabled when you configure the Python with the --disable-gil option which is nothing but a build configuration (free threading build) at the time of installation.

This will allow optionally enabling and disabling GIL using the environment variable PYTHON_GIL which can be set to 1 and 0 respectively.

It will also provide a command-line option -X gil which can also be set to 0 (disable) and 1 (enable).

you are viewing a single comment's thread
view the rest of the comments

[–] stuckgum@lemmy.ml 0 points 1 month ago (2 children)

For multithreaded applications, just don’t use python.

[–] mox@lemmy.sdf.org 20 points 1 month ago* (last edited 1 month ago) (1 children)

For multithreaded CPU-bound applications, just don’t use pure python, unless the intensive work is done in a compiled module. (Those have always been able to run without the GIL, there are a bunch of them in the standard library and other popular packages, and the API for writing custom ones is pretty good.)

FTFY

[–] atzanteol@sh.itjust.works 0 points 1 month ago (1 children)

Python performance sucks - use C if it matters.

FTFY

[–] mox@lemmy.sdf.org 5 points 1 month ago

C is one option for writing compiled modules, but certainly not the only one.

More importantly, writing a moderate-sized program entirely in C when only a small fraction of it needs high-performance custom behavior is likely a poor use of time, both immediately and throughout the code's life.

[–] xmunk@sh.itjust.works 6 points 1 month ago

It is a bad language choice for that need but a lot of people don't have a choice or aren't the decision makers.