[Martin v. L=F6wis]
> I'd like to replace the first sentence of 8.1 in the API reference
> with
>
> "The Python interpreter does not support \emph{free} threading."
I agree it should change, but doubt this rephrasing would help much. =
Do a
Google search on "free threading", and you'll find that all the top h=
its are
about Microsoft, or about Python (thanks to GregS and MarkH importing=
this
MS terminology into PythonLand). People on other OSes aren't likely =
to have
a clue what it means. I can predict that with confidence because I h=
ad no
idea what they were talking about when I first heard the term in Pyth=
onLand,
and despite working in the parallel processing biz at the time <wink>=
.
For most people, I believe "thread safe" means that a collection of A=
PI
calls is safe to make without any special dances. For example, under=
some
Unix flavors, routines whose names end with _r are the "thread safe"
versions of routines without the trailing _r.
Under that meaning (which I believe Guido also had in mind when he wr=
ote
this section), Python's C API is indeed not thread-safe. We don't ha=
ve to
apologize for that, though, we just have to spell out what's needed i=
n the
presence of threads. Since people are apt to misunderstand the inten=
ded
meanings of both "thread safe" and "free threading", better to just e=
xplain
what's needed than to shoot for buzzword compliance.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4