gh-108337: Add pyatomic.h header #108338

colesbury · 2023-08-22T20:12:02Z

This adds a new header that provides atomic operations on common data types.

Implementing PEP 703 requires use of atomic operations on more data types than provided by pycore_atomic.h. Additionally, pycore_atomic.h is only usable from Py_BUILD_CORE modules; it can't be used in public headers. PEP 703 will require atomic operations in object.h for Py_INCREF/DECREF, for example. The intention is that this will be exposed through Python.h, although that is not the case yet.

To avoid build issues in third-party extensions, the pyatomic.h header generally does not require -std=gnu11 or -std=c11 to be passed to the compiler (for GCC or Clang). When compiling C, MSVC will use the pyatomic_msc.h, which uses compiler intrinsics. When compiled in C++ mode, MSVC will use the pyatomic_std.h implementation, which uses C++11 atomics.

Issue: Expand pyatomic coverage #108337

This adds a new header that provides atomic operations on common data types. The intention is that this will be exposed through Python.h, although that is not the case yet. The only immediate use is in the test file.

Placates Tools/c-analyzer/check-c-globals.py.

vstinner · 2023-08-22T21:34:30Z

it can't be used in public headers

Is this API public or private? Names are prefixed by _Py, so it looks private. I'm trying to remove private APIs from the public API, rather than adding them :-) Should it be usable by 3rd party projects? Or is it ok to restrict its usage to Python?

At least, I suggest to exclude it from the limited C API for now: so move it to cpython/ directory, and check for Py_LIMITED_API. See other header files like Include/cpython/pydebug.h, the ones included with cpython/ in Python.h.

I like the approach using functions rather than atomic types: it's the approach used by the glib library: https://developer-old.gnome.org/glib/stable/glib-Atomic-Operations.html I'm curious why/how some function parameters don't need volatile, like g_atomic_int_inc():

While atomic has a volatile qualifier, this is a historical artifact and the pointer passed to it should not be volatile.

I wrote Include/internal/pycore_atomic_funcs.h which tries to address Include/internal/pycore_atomic.h compiler issues. But pycore_atomic_funcs.h is incomplete and was only used for a very few things (is it still used?).

Using atomic variables is hard :-( Do you have any kind of documentation? Or links to other documentations?

It would be good to have a doc, at least in pyatomic.h.

encukou · 2023-08-23T08:52:27Z

Is this API public or private? Names are prefixed by _Py, so it looks private. I'm trying to remove private APIs from the public API, rather than adding them :-) Should it be usable by 3rd party projects? Or is it ok to restrict its usage to Python?

They are private, but they're static inline functions that will be used by public static inline functions/macros (Py_INCREF/DECREF). So they need to be visible to the compiler without Py_BUILD_CORE.
The leading underscore is the way to go here.

Although, Include/pyatomic.h should go in Include/cpython too -- it's not stable ABI.

But pycore_atomic_funcs.h is incomplete and was only used for a very few things (is it still used?).

Yes, but AFAICS the uses can be replaced.

colesbury · 2023-08-23T17:52:26Z

As @encukou wrote, the intention is that they're private and only used directly by CPython for now. I'll move them to the Include/cpython directory.

Regarding volatile, it's only meaningful for the MSVC implementation, which doesn't support C11 atomics yet (*). This can be pushed down into the MSVC function bodies so it's no longer part of the common function signatures.

I'll add some code documentation and links in pyatomic.h

(*) There's experimental support in the most recent builds.

Instead use volatile casts in MSVC implementation where they are meaningful.

vstinner · 2023-08-23T19:21:35Z

the intention is that they're private and only used directly by CPython for now

Unless there is a good reason to expose this API to 3rd party code, I would suggest to move it to Include/internal/. For example, override pycore_atomic_funcs.h.

If the header file is only exposed in the internal C API, we will have less compilation issues.

Even after I moved Include/pyatomic.h to Include/internal/pycore_pyatomic.h, people get compilation errors... Someone wants to use pycore_dict.h in C++, but pycore_dict.h indirectly includes pycore_pyatomic.h which is incompatible with C++ :-( See #108216 bug report (feature request? :-)).

Is your header file, declaration and implementation (since there are static inline functions, the implementation is public!), compatible with C++?

To avoid compilation issues, would it be technically possible to have:

internal C API: fast static inline implementation, name prefixed by Py_, implemented in header files.
public C API: slow regular functions (opaque function calls, similar to the glib library), name prefixed by Py. Implementation calls the internal C API.

encukou · 2023-08-23T19:21:49Z

Oh, right, atomics are an optional C11 feature!

As far as I can see, the current pycore_atomic.h has an unsafe fallback to volatile, which is presumably OK-ish for systems/compilers without atomics? That feels a bit cheaty. IMO, we should just explicitly require C11/C++/MSVC atomics.

PEP-7 should be updated, and this should get a What's New entry similar to the 3.11 one for "Building CPython". You might want have PEP-703 state the compiler requirement explicitly.

zooba · 2023-08-23T19:29:49Z

To avoid compilation issues, would it be technically possible to have:

internal C API: fast static inline implementation, name prefixed by Py_, implemented in header files.

public C API: slow regular functions (opaque function calls, similar to the glib library), name prefixed by Py. Implementation calls the internal C API.

I agree with this, but I suspect we're going to need these available for macros/inlines. So they'll have to be available in the public API, even if they're not intended for direct use.

Stabe API shouldn't include them, obviously, which means any that's currently a macro/inline for the stable API can't use them either and needs an opaque function call.

colesbury · 2023-08-23T19:39:28Z

@vstinner:

The code will be used indirectly in other static inline functions that are public so it needs to be visible; it can't be in Include/internal because it will need to be used by, for example, the static inline Py_INCREF function.
This implementation avoids the compilation errors people saw with pycore_pyatomic.h because of the preference builtins/intrinsics. (i.e., it doesn't require -std=c11 and can be compiled by a C++ compiler)

@encukou:

I'll update the what's new, but practically, this does not change compiler requirements from 3.11.

@zooba:

Yeah, as you wrote, we're going to need these available for macros/inlines. I think we can avoid using them in the stable ABI.

vstinner · 2023-08-23T19:42:29Z

The code will be used indirectly in other static inline functions that are public

Oh ok, now I get it. It wasn't clear when I first reviewed your PR. In that case, it can be in Include/cpython/.

Do you know if you need any atomic function in Include/ header files (limited C API)?

colesbury · 2023-08-23T19:54:56Z

@vstinner:

Do you know if you need any atomic function in Include/ header files (limited C API)?

In Include/object.h but only when Py_LIMITED_API is not defined. (For reference counting in --disable-gil builds.)

pitrou · 2023-08-23T20:09:18Z

Include/cpython/pyatomic.h

+
+// Performs an atomic compare-and-exchange. If `*address` and `expected` are equal,
+// then `value` is stored in `*address`. Returns 1 on success and 0 on failure.
+// These correspond to the "strong" variations of the C11 atomic_compare_exchange_* functions.


C11 passes expected as a pointer, so that it's updated with the actual value when the latter doesn't match the former. Why not keep that convention here?

The motivation was two-fold: First, many of the _Py_atomic_compare_exchange calls in the nogil fork use constants as expected and this would be more verbose if it needs to be a pointer, e.g.:

_Py_atomic_compare_exchange_uint8(&m->v, LOCKED, UNLOCKED)

vs.

uint8_t expected = LOCKED: _Py_atomic_compare_exchange_uint8(&m->v, &expected, UNLOCKED)

Second, I find this style (no pointer for expected) to be a bit less error-prone. I've been tripped up once or twice by having expected be modified when I didn't expect it.

I don't feel terribly strongly about this, so if there is a general preference for sticking closer to the C11-style API here, I can change it.

AFAIU the main motivation for the C11 style APIs is for retry loops in lockless data structure implementations. A simplistic example (this may be embarassingly wrong):

struct ListNode; typedef struct ListNode { int value; struct ListNode* next; } ListNode; void ListAppend(ListNode* list, int new_value) { ListNode* new_node = (ListNode*) malloc(sizeof ListNode); new_node->value = new_value; new_node->next = NULL; ListNode* expected = NULL; while (_Py_atomic_compare_exchange_ptr(&list->next, &expected, new_node)) { list = expected; expected = NULL; } }

If the second argument is a reference (&expected), does it mean that it changes the value of the second argument (*expected)?

For C11 atomic_exchange(), the second argument is not a pointer, but a value (integer), no? https://en.cppreference.com/w/c/atomic/atomic_exchange

C11 atomic_compare_exchange_strong() and atomic_compare_exchange_weak() use a pointer for expected. But this API writes into *expected if the *obj is not equal to *expected.

The behavior of atomic_compare_exchange_* family is as if the following was executed atomically:

if (memcmp(obj, expected, sizeof *obj) == 0) { memcpy(obj, &desired, sizeof *obj); return true; } else { memcpy(expected, obj, sizeof *obj); return false; }

For this header fie, I would prefer to not have two flavors, the API is already quite long! I would prefer to have a single flavor. If there is an usecase where setting expected is relevant, I suggest to use a pointer for the second argument.

In short, I agree to change the API to int _Py_atomic_compare_exchange_int32(int32_t *obj, int32_t *expected, int32_t desired). The behavior should be well documented.

obj, expected and desired names come from the C11 API.

I'll make the second argument a pointer like the C11 API.

pitrou · 2023-08-23T20:09:46Z

Include/cpython/pyatomic.h

+_Py_atomic_add_uintptr(uintptr_t *address, uintptr_t value);
+
+static inline Py_ssize_t
+_Py_atomic_add_ssize(Py_ssize_t *address, Py_ssize_t value);


Not sure it's worth exposing atomic ops for all int sizes and signednesses?

I expect to use at least one atomic operation on each of the data types here (but not every atomic op on every data type). I tried to be consistent on what's defined because it makes understanding what's available easier and testing easier.

pitrou · 2023-08-23T20:10:36Z

Include/cpython/pyatomic.h

+_Py_atomic_compare_exchange_ssize(Py_ssize_t *address, Py_ssize_t expected, Py_ssize_t value);
+
+static inline int
+_Py_atomic_compare_exchange_ptr(void *address, void *expected, void *value);


Should it be void** address for clarity?

The problem is that void ** requires an explicit cast for almost every use, because things like PyObject ** are not implicitly convertible to void **. In other words, currently we can write things like:

PyObject *old_exc = _Py_atomic_exchange_ptr(&tstate->async_exc, exc);

but if address was void **address, we'd have to write:

PyObject *old_exc = _Py_atomic_exchange_ptr((void **)&tstate->async_exc, exc);

A large part of the Python C API uses macro to convert arguments to PyObject*. Would it make sense to do the same here?

#define _Py_atomic_exchange_ptr(atomic, value) _Py_atomic_exchange_ptr(_Py_CAST(void**, atomic), (value))

I don't see the benefit of that style over the current approach, and it would silently allow passing some integer types to _Py_atomic_exchange_ptr.

Right, in that case I'm fine with the surprising void* type.

pitrou · 2023-08-23T20:13:20Z

Include/cpython/pyatomic.h

+_Py_atomic_store_uint64_release(uint64_t *address, uint64_t value);
+
+static inline void
+_Py_atomic_store_ptr_release(void *address, void *value);


I'm not an expert, but why is it useful to expose "release" operations if no "acquire" operations are exposed?

You can always use stronger orderings for correctness (i.e., "seq_cst" everywhere instead of "acquire"). From a performance view, "release" is substantially faster than "seq_cst" stores on x86/x86-64, but "acquire" generates the same code as "seq_cst" loads on both x86/x86-64 and aarch64.

I don't think CPython support is limited to x86 and ARM variants, so the set of atomic ops exposed should probably be made consistent nevertheless?

Also, using "seq_cst" in combination with "release" will probably make the code more difficult to reason about, than if "acquire" is exposed (and memory ordering is already hard to reason about!).

I'll add a _Py_atomic_load_ptr_acquire for consistency (and I think I can remove the _Py_atomic_store_uint64_release).

vstinner

It's unclear to me if volatile must be used on the first parameter in the function definition, or not. For me, it's surprising to be able to cast int* to volatile long* in pyatomic_msc.h. Maybe explain the black magic in the documentation at the top of pyatomic.h?

I'm scared by the _ptr variant which takes a void* and is then casted to a pointer of a pointer (void**). It looks suspicious.

Include/cpython/pyatomic.h

vstinner · 2023-08-23T20:02:07Z

Include/cpython/pyatomic_gcc.h

+#  error "this header file must not be included directly"
+#endif
+
+// This is the implementation of Python atomic operations using GCC's built-in


I suggest moving it at the top of the file.

vstinner · 2023-08-23T20:03:32Z

Include/cpython/pyatomic_gcc.h

+static inline int
+_Py_atomic_add_int(int *address, int value)
+{
+    return __atomic_fetch_add(address, value, __ATOMIC_SEQ_CST);
+}


Usually, I prefer verbose syntax like the one that you used. But in this header file, you have tons of static inline functions, so I suggest using the compact syntax:

Suggested change

static inline int

_Py_atomic_add_int(int *address, int value)

{

return __atomic_fetch_add(address, value, __ATOMIC_SEQ_CST);

}

static inline int

_Py_atomic_add_int(int *address, int value)

{ return __atomic_fetch_add(address, value, __ATOMIC_SEQ_CST); }

Include/cpython/pyatomic_msc.h

vstinner · 2023-08-23T20:32:59Z

Include/cpython/pyatomic.h

+_Py_atomic_store_ptr_release(void *address, void *value);
+
+
+// Sequential consistency fence


I would prefer a more elaborated documentation, "fence" is kind of weak.

__faststorefence doc:

Guarantees that every previous memory reference, including both load and store memory references, is globally visible before any subsequent memory reference.

_ReadWriteBarrier doc:

Limits the compiler optimizations that can reorder memory accesses across the point of the call.

dmb ish:

The data memory barrier ensures that all preceding writes are issued before any subsequent memory operations (including speculative memory access).

The challenge I have is that it's really hard to describe what fences do in a way that's helpful and accurate. The above documentation is too strong for C11 fences.

There's https://en.cppreference.com/w/c/atomic/atomic_thread_fence, but I find it vague. And the C++ documentation (https://en.cppreference.com/w/cpp/atomic/atomic_thread_fence) is more detailed but really hard to understand.

Please add one or two of these links here. It's ok to have references to external doc, it's better than no doc :-)

colesbury · 2023-08-24T18:25:33Z

I have made the requested changes; please review again.

bedevere-bot · 2023-08-24T18:25:37Z

Thanks for making the requested changes!

@vstinner: please review the changes made to this pull request.

vstinner

The glib library provides g_atomic_int_dec_and_test() to implement reference counting. How would you reimplement it with your API? I'm not used to atomic variables and I never know how to use them correctly.

vstinner · 2023-08-24T18:41:10Z

Include/cpython/pyatomic.h

+_Py_atomic_store_ptr_release(void *address, void *value);
+
+
+// Sequential consistency fence


Please add one or two of these links here. It's ok to have references to external doc, it's better than no doc :-)

colesbury · 2023-08-24T18:59:21Z

The glib library provides g_atomic_int_dec_and_test() to implement reference counting. How would you reimplement it with your API?

The decrement would look like the following. The atomic_add functions return the previous value like the C11/C++11 atomic_fetch_add function.

if (_Py_atomic_add_ssize(&op->ob_refcnt, -1) == 1) {
  // refcnt is zero, dealloc
}

colesbury · 2023-08-29T14:58:36Z

@vstinner, would you please look this over again when you have a chance?

vstinner

We should decide _Py_atomic_compare_exchange() second argument should be a pointer or not. Apparently, a pointer covers more cases and so should be used.

vstinner · 2023-08-29T17:33:06Z

PCbuild/pythoncore.vcxproj.filters

+    <ClInclude Include="..\Include\cpython\pyatomic_msc.h">
+      <Filter>Include</Filter>
+    </ClInclude>


You should add GCC here:

Suggested change

<ClInclude Include="..\Include\cpython\pyatomic_msc.h">

<Filter>Include</Filter>

</ClInclude>

<ClInclude Include="..\Include\cpython\pyatomic_gcc.h">

<Filter>Include</Filter>

</ClInclude>

<ClInclude Include="..\Include\cpython\pyatomic_msc.h">

<Filter>Include</Filter>

</ClInclude>

It's just for the UI, not to build Python.

vstinner · 2023-08-29T17:37:12Z

Include/cpython/pyatomic.h

+
+// Atomically adds `value` to `address` and returns the previous value
+static inline int
+_Py_atomic_add_int(int *address, int value);


https://en.cppreference.com/w/c/atomic uses obj name.

https://www.ibm.com/docs/en/zos/2.1.0?topic=c11-atomic-load also uses obj name (C11 functions)

pycore_atomic.h uses ATOMIC_VAL name

pycore_atomic_func.h uses var name

I dislike the address name. What you pass is not a void* pointer or an uintptr_t address, but a reference to an atomic variable. I suggest to use atomic or obj name.

For add operation, the C11 API uses arg for the second parameter name. I'm fine with value.

vstinner · 2023-08-29T17:41:45Z

Include/cpython/pyatomic.h

+
+// Performs an atomic compare-and-exchange. If `*address` and `expected` are equal,
+// then `value` is stored in `*address`. Returns 1 on success and 0 on failure.
+// These correspond to the "strong" variations of the C11 atomic_compare_exchange_* functions.


If the second argument is a reference (&expected), does it mean that it changes the value of the second argument (*expected)?

For C11 atomic_exchange(), the second argument is not a pointer, but a value (integer), no? https://en.cppreference.com/w/c/atomic/atomic_exchange

C11 atomic_compare_exchange_strong() and atomic_compare_exchange_weak() use a pointer for expected. But this API writes into *expected if the *obj is not equal to *expected.

The behavior of atomic_compare_exchange_* family is as if the following was executed atomically:

if (memcmp(obj, expected, sizeof *obj) == 0) { memcpy(obj, &desired, sizeof *obj); return true; } else { memcpy(expected, obj, sizeof *obj); return false; }

For this header fie, I would prefer to not have two flavors, the API is already quite long! I would prefer to have a single flavor. If there is an usecase where setting expected is relevant, I suggest to use a pointer for the second argument.

In short, I agree to change the API to int _Py_atomic_compare_exchange_int32(int32_t *obj, int32_t *expected, int32_t desired). The behavior should be well documented.

obj, expected and desired names come from the C11 API.

vstinner · 2023-08-29T17:54:53Z

Include/cpython/pyatomic.h

+_Py_atomic_compare_exchange_ssize(Py_ssize_t *address, Py_ssize_t expected, Py_ssize_t value);
+
+static inline int
+_Py_atomic_compare_exchange_ptr(void *address, void *expected, void *value);


Right, in that case I'm fine with the surprising void* type.

- Add pyatomic_*.h headers to MSVC filters - Use a pointer for 2nd argument of compare_exchange functions - Rename address to ptr

colesbury · 2023-08-29T19:44:49Z

@vstinner, I've made the second argument to _Py_atomic_compare_exchange_ functions a pointer. I renamed the first argument to all the atomic functions to ptr for the reasons in my above comment. I can change it to obj if you prefer.

Include/cpython/pyatomic.h

Co-authored-by: Victor Stinner <[email protected]>

vstinner · 2023-08-30T16:02:11Z

I renamed the first argument to all the atomic functions to ptr for the reasons in my above comment. I can change it to obj if you prefer.

Please rename the argument to obj.

Naming is a hard problem :-( If I want to write documentation for that, I would have issues to explain why I have to pass a "pointer" (ptr) to these functions.

https://en.cppreference.com/w/c/atomic/atomic_load says:

Parameters
obj - pointer to the atomic object to access
order - the memory synchronization ordering for this operation

The first argument is a pointer to the atomic object to access.

It's right that it's a pointer, so "atomic_ptr", "atomic_obj_ptr", "patomic", ... names would be good. But to make the name shorter, I would suggest to omit "pointer", and so just say "object" (or "atomic", but you dislike this name, so let's skip it).

I would prefer to document that _Py_atomic_load_int32(obj) gets the value of the atomic object obj, rather than the value of the atomic pointer ptr.

pitrou · 2023-08-30T16:09:31Z

"object" in a CPython context is really misleading. I also don't understand what the issue with "pointer" or "ptr" is.

vstinner · 2023-08-30T16:11:48Z

"object" in a CPython context is really misleading. I also don't understand what the issue with "pointer" or "ptr" is.

I would prefer to be as close as possible to C11 API. It doesn't matter that C11 API made bad decisions, the API is now standardized :-)

pitrou · 2023-08-30T16:12:53Z

As you prefer... This is a private low-level API anyway, so the name of arguments is hardly fundamental.

colesbury · 2023-08-30T16:23:11Z

I've renamed ptr to obj

vstinner · 2023-08-31T00:03:51Z

Well. I have "a few more remarks", but I decided to copy this PR and make my changes directly there: please see my PR #108701.

vstinner · 2023-08-31T21:49:54Z

I merged #108701 which includes my coding style changes. Thanks!

pythongh-108337: Add pyatomic.h header

2bc82a6

This adds a new header that provides atomic operations on common data types. The intention is that this will be exposed through Python.h, although that is not the case yet. The only immediate use is in the test file.

colesbury added topic-C-API 3.13 bugs and security fixes labels Aug 22, 2023

colesbury requested a review from vstinner August 22, 2023 20:12

colesbury requested a review from a team as a code owner August 22, 2023 20:12

bedevere-bot mentioned this pull request Aug 22, 2023

Expand pyatomic coverage #108337

Closed

bedevere-bot added the awaiting review label Aug 22, 2023

colesbury added 3 commits August 22, 2023 13:16

Fix blurb name

9adf4f8

Move pyatomic_std/gcc/msc.h to Include/cpython

d70e8ae

Placates Tools/c-analyzer/check-c-globals.py.

Fix _InterlockedCompareExchange64 calls on MSVC x86

927430d

colesbury added 3 commits August 23, 2023 10:58

Move pyatomic.h to Include/cpython

2d6f950

Remove volatile from function signature.

bf27448

Instead use volatile casts in MSVC implementation where they are meaningful.

Add code documentation to pyatomic.h

60b56f1

colesbury requested a review from encukou as a code owner August 23, 2023 19:01

colesbury added 2 commits August 23, 2023 12:02

Fix typo

0131868

Revert inadvertent change to stable_abi.py

0474e2f

pitrou reviewed Aug 23, 2023

View reviewed changes

vstinner requested changes Aug 23, 2023

View reviewed changes

Describe volatile meaning on MSVC.

2d08290

bedevere-bot added awaiting change review and removed awaiting changes labels Aug 24, 2023

bedevere-bot requested a review from vstinner August 24, 2023 18:25

vstinner reviewed Aug 24, 2023

View reviewed changes

Add link to atomic_thread_fence documentation

71d981e

Fix _Py_atomic_exchange_int64 on 32-bit Windows

457ce21

vstinner reviewed Aug 29, 2023

View reviewed changes

colesbury added 2 commits August 29, 2023 11:25

Add pyatomic_gcc/std.h to vcxproj filters

9dd0f0b

Changes from review:

7611965

- Add pyatomic_*.h headers to MSVC filters - Use a pointer for 2nd argument of compare_exchange functions - Rename address to ptr

vstinner reviewed Aug 30, 2023

View reviewed changes

Include/cpython/pyatomic.h Outdated Show resolved Hide resolved

Update Include/cpython/pyatomic.h

a8e2538

Co-authored-by: Victor Stinner <[email protected]>

Rename ptr to obj

433319f

vstinner mentioned this pull request Aug 31, 2023

gh-108337: Add pyatomic.h header #108701

Merged

vstinner closed this Aug 31, 2023

colesbury deleted the pyatomic branch August 31, 2023 21:56

colesbury mentioned this pull request Sep 14, 2023

gh-108724: Add PyMutex and _PyParkingLot APIs #109344

Merged

zanieb mentioned this pull request Jan 26, 2025

gh-129296: Fix pyatomic.h include paths #129320

Merged

		_Py_atomic_store_ptr_release(void address, void value);


		// Sequential consistency fence

gh-108337: Add pyatomic.h header #108338

gh-108337: Add pyatomic.h header #108338

Conversation

colesbury commented Aug 22, 2023 • edited by bedevere-bot Loading

vstinner commented Aug 22, 2023

encukou commented Aug 23, 2023

colesbury commented Aug 23, 2023

vstinner commented Aug 23, 2023 • edited Loading

encukou commented Aug 23, 2023

zooba commented Aug 23, 2023

colesbury commented Aug 23, 2023 • edited Loading

vstinner commented Aug 23, 2023

colesbury commented Aug 23, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vstinner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

colesbury commented Aug 24, 2023

bedevere-bot commented Aug 24, 2023

vstinner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

colesbury commented Aug 24, 2023

colesbury commented Aug 29, 2023

vstinner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

colesbury commented Aug 29, 2023

vstinner commented Aug 30, 2023

pitrou commented Aug 30, 2023

vstinner commented Aug 30, 2023

pitrou commented Aug 30, 2023

colesbury commented Aug 30, 2023

vstinner commented Aug 31, 2023

vstinner commented Aug 31, 2023

colesbury commented Aug 22, 2023 •

edited by bedevere-bot

Loading

vstinner commented Aug 23, 2023 •

edited

Loading

colesbury commented Aug 23, 2023 •

edited

Loading