[Python-Dev] The Python interpreter is not fully thread-safe.

[Martin v. Löwis]

Tim Peters <tim.one@comcast.net> writes:

> 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 hits 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.  

True. I think I'll add a footnote as well.

> For most people, I believe "thread safe" means that a collection of API
> 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.

Actually, Unix people tend to call those "re-entrant"; this is what
the _r suffix suggests, anyway. It is almost correct to say that the
Python API is not re-entrant. 

However, traditionally, this term was defined as "re-enter the
function while it is being running". In this definition, the Python
API *does* support certain kinds of reentrancy, namely those where the
API is re-entered from the same thread.

> Under that meaning (which I believe Guido also had in mind when he wrote
> this section), Python's C API is indeed not thread-safe.  We don't have to
> apologize for that, though, we just have to spell out what's needed in the
> presence of threads.

This request was triggered by a question from c.l.p: "When will Python
be thread-safe". It was not obvious that the poster was referring to
the API docs, so the initial responses all were "Python *is* thread-safe".

Regards,
Martin