You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: mypyc/doc/differences_from_python.rst
+40-4Lines changed: 40 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -260,6 +260,45 @@ When run as interpreted, the first example will execute slower due to
260
260
the extra namespace lookups. In interpreted code final attributes can
261
261
also be modified.
262
262
263
+
.. _free-threading:
264
+
265
+
Free threading
266
+
--------------
267
+
268
+
Mypyc has basic support for free threading, but it doesn't provide the
269
+
same memory safety guarantees as Python in compiled modules, since
270
+
in current Python versions this would cause an unacceptable performance
271
+
impact.
272
+
273
+
The exact details of the memory safety in the presence of data races
274
+
are likely to evolve in the future. Currently, compiled code must
275
+
ensure that proper synchronization is used to prevent data races. In
276
+
particular, these operations require explicit synchronization, such as
277
+
via ``threading.Lock``, if there is a possibility of data races
278
+
(the list is not exhaustive):
279
+
280
+
* Reads or writes of non-final instance data attributes of native
281
+
classes.
282
+
* List item access or iteration using a ``list`` static type (using
283
+
``Sequence`` or ``MutableSequence`` as the type ensure correct
284
+
implicit synchronization).
285
+
* Dict item access using a static ``dict`` type (using ``Mapping``
286
+
or ``MutableMapping`` ensures correct implicit synchronization).
287
+
288
+
As libraries often won't be able to control the concurrent access by
289
+
user code, we recommend that modules document that multi-threaded
290
+
access is only supported via public interfaces that ensure correct
291
+
synchronization. Marking attributes as internal using an underscore
292
+
attribute prefix is another possibility, but this is not enforced at
293
+
runtime. Another option is to document that multithreaded access is
294
+
not supported, or that particular objects should not be used from
295
+
multiple threads concurrently.
296
+
297
+
It's always safe to perform read-only operations concurrently. Using
298
+
objects with final attributes and tuple objects can help prevent
299
+
race conditions without introducing extra overhead from explicit
300
+
synchronization operations.
301
+
263
302
Unsupported features
264
303
--------------------
265
304
@@ -284,10 +323,8 @@ Dunder methods
284
323
Native classes **cannot** use these dunders. If defined, they will not
285
324
work as expected.
286
325
287
-
* ``__del__``
288
326
* ``__index__``
289
-
* ``__getattr__``, ``__getattribute__``
290
-
* ``__setattr__``
327
+
* ``__getattribute__``
291
328
* ``__delattr__``
292
329
293
330
Generator expressions
@@ -318,7 +355,6 @@ non-exhaustive list of what won't work:
318
355
- Compiled methods aren't considered methods by ``inspect.ismethod``
319
356
- ``inspect.signature`` chokes on compiled functions with default arguments that
320
357
are not simple literals
321
-
- ``inspect.iscoroutinefunction`` and ``asyncio.iscoroutinefunction`` will always return False for compiled functions, even those defined with `async def`
0 commit comments