gh-142518: Annotate PyDict_* C APIs for thread safety#145875
gh-142518: Annotate PyDict_* C APIs for thread safety#145875lysnikolaou wants to merge 4 commits intopython:mainfrom
Conversation
|
|
||
| The operation is atomic in the :term:`free-threaded build`, if *key* | ||
| is a builtin type (e.g. :class:`str`, :class:`int`, :class:`float`) or any | ||
| other object which does not define :meth:`~object.__hash__` and :meth:`~object.__eq__` methods. |
There was a problem hiding this comment.
Don't most objects have __hash__ and __eq__?
What's the real requirement here? If I define a built-in type, what property do its tp_hash/tp_richcompare need to have to keep this atomic?
There was a problem hiding this comment.
Don't most objects have hash and eq?
They have but it is inherited from object, here the docs mean user-defined methods which override it.
What's the real requirement here? If I define a built-in type, what property do its tp_hash/tp_richcompare need to have to keep this atomic?
The real requirements are the function should not call back into Python or the C-API and not release the thread state. All of this is implementation defined and subject to change hence it is not documented.
There was a problem hiding this comment.
The way this is written guarantees that all built-in types have this property.
But, tuple or frozendict don't, and for some others I'd consider it an implementation detail.
How do I tell whether we guarantee that a given type doesn't release thread state in __eq__/__hash__? It's easy for str/int/float, but there's a lot of other built-in types.
4 participants
📚 Documentation preview 📚: https://cpython-previews--145875.org.readthedocs.build/