4 ms·

Because with the GIL it was dead simple to glue a C library into Python, and also was the canonical way to address hot inner loops in Python: rewrite into C. No

Because with the GIL it was dead simple to glue a C library into Python, and also was the canonical way to address hot inner loops in Python: rewrite into C. Nothing fancy but a little trial and error with module loading and you get 30% speed ups without being a great C programmer. I don’t think it’s false to say that the ease of moving hot spots into C is part of the reason Python has been so successful for thirty years. I hope this works, but I am very sceptical about being able to port code that worked with a locking solution provided for the enthusiast trying out C working without running into concurrency bugs.

Cacti 3y ago
My understanding is the thing about the binding system that drove adoption more than anything was due to how easy it was to generate bindings for an existing C library. This drove stdlib expansion and allowed rapid repurpose of huge amounts of long-standing and popular C libraries, and it also added instant credibility for those that already trusted those libraries. This helped avoid the chicken and egg problem of not enough devs for a serious stdlib, but not serious enough stdlib to draw dev (which is where most languages, even good ones, die). I distinctly remember that during the time period where Python grew from “minor” to “dominate” (roughly 1995-2005), doing Python dev was often a process of answering “are there bindings for that?” And usually _there were_, because of that tooling.
d0mine 3y ago
btw, many C extensions release GIL already e.g., one Python thread can do regex work, another some number crunching, yet another waiting IO--all in parallel.
samus 3y ago
C extensions are a different use case than accessing a C library using `ctypes`. The former allows intimate interactions with Python objects and therefore requires the GIL. The latter should only cause trouble if the C library executes callbacks on another thread. In that case, a Python thread is created for every invocation, which could cause race conditions with Python code. However, this problem also exists in GIL mode. In most cases, foreign libraries usually have Pythonic wrappers that should prevent some of these issues.

Cacti 3y ago

My understanding is the thing about the binding system that drove adoption more than anything was due to how easy it was to generate bindings for an existing C library. This drove stdlib expansion and allowed rapid repurpose of huge amounts of long-standing and popular C libraries, and it also added instant credibility for those that already trusted those libraries. This helped avoid the chicken and egg problem of not enough devs for a serious stdlib, but not serious enough stdlib to draw dev (which is where most languages, even good ones, die). I distinctly remember that during the time period where Python grew from “minor” to “dominate” (roughly 1995-2005), doing Python dev was often a process of answering “are there bindings for that?” And usually _there were_, because of that tooling.

d0mine 3y ago

btw, many C extensions release GIL already e.g., one Python thread can do regex work, another some number crunching, yet another waiting IO--all in parallel.

samus 3y ago

C extensions are a different use case than accessing a C library using `ctypes`. The former allows intimate interactions with Python objects and therefore requires the GIL. The latter should only cause trouble if the C library executes callbacks on another thread. In that case, a Python thread is created for every invocation, which could cause race conditions with Python code. However, this problem also exists in GIL mode. In most cases, foreign libraries usually have Pythonic wrappers that should prevent some of these issues.