If we are only talking about native code (C or C++ or Rust or whatever), maybe we should leave this out of the glossary for now.

Hmm, not sure about this. The fact that a program might be crashing because of a data race in native code affects Python programmers, so maybe it warrants at least an entry in the glossary. It'll also be nice to be able to link to this glossary entry from other places where we talk about data races.

One idea we had was for ecosystem documentation to link back here. In that context it'll really help.

Having both data race and race condition feels a bit redundant. Wouldn't ecosystem libraries be able to only refer to race conditions?

Am I guessing correctly that here you want to distinguish between races that produce errors in application logic and races that produce a segfault or something low-level like that? If that's the case it might be useful when talking about bug reports, yes. But it might be a bit niche, hopefully?

Extension modules can cause data races, so I feel it's appropriate to talk about both, especially since data races are undefined behavior.

One idea we had was for ecosystem documentation to link back here. In that context it'll really help.

maybe worth bringing up context variables as well?

Maybe we should add an item for thread-local state instead?

I think this one's very tricky, definitely because thread-safe in itself is very vague.

I took a look at my uni textbook on concurrency and couldn't find a definition of thread-safe. (I checked, it actually never mentions thread-safe or thread safe.) And I think that's because what thread-safe means fundamentally depends on the semantics of an application.

Is it thread-safe to call my_list[0] += 1, assuming my_list is shared? It depends. And that's why there is this unsatisfactory line here:

[...] built-in types like
:class:`dict`, :class:`list`, and :class:`set` use internal locking
to make many operations thread-safe, although thread safety is not
necessarily guaranteed.

Maybe we can turn the problem around and only define thread-safety as the absence of thread-unsafety?

Yes, talking about thread-safety is always bound to be vague. Having said that, the sentence about dict, list and set feels like it's okay since it doesn't necessarily make any statement, but makes the reader understand that there's subtlety there which they can found out more about in other places in the docs.

Having both data race and race condition feels a bit redundant. Wouldn't ecosystem libraries be able to only refer to race conditions?

Am I guessing correctly that here you want to distinguish between races that produce errors in application logic and races that produce a segfault or something low-level like that? If that's the case it might be useful when talking about bug reports, yes. But it might be a bit niche, hopefully?

To me it feels more correct to imply race conditions here.

Also, the previous definition was mentioning id(). Why not keep that? It might help newcomers make the connection and learn that they can check the id(obj) to know whether obj is shared. (Especially useful in debugging sessions.)

Hmm, this is something we discussed with Nathan and we both agreed that using id to define mutable will confuse more people than it'll help. The advice about using id is a good one though, but maybe it best-positioned somewhere else?