scoder

> What is the `Py_SIZE()` of Cython code objects? The "byte code" in Cython's code objects is currently a zero-initialised byte string that is a little longer than the PEP-626...

So, I looked over this and read through the documentation snippets, but I still feel unsure about the goal and effects of this change. I gathered that the new `with_python=True`...

> It's pretty close to writing > ```python > for i in prange(N, nogil=True): > with gil: > ... # code > ``` > It's _slightly_ more efficient So …...

> Right now you get a compile-time error if you try to write a `prange` loop without releasing the GIL. Ah, so, we basically push people into releasing the GIL...

BTW, we don't have any benchmarks for our parallel code, neither micro nor macro. Since you're working on the freethreading and parallel code, maybe you could come up with at...

> freethreading_compatible=True Isn't this a good indicator for whether we should warn about the GIL being released or not when we enter a prange loop? Even with your speed improvement,...

> * Remove the explicit `with_gil` directive, > * If the user omits `nogil=True` then don't error - let them use the GIL. > * Warn if they don't release...

I agree that this is desirable. This can be implemented in https://github.com/cython/cython/blob/bf59121ba5c9f79b4bbfeab05407c15e07e4cb15/Cython/Utility/CppConvert.pyx#L4-L16

Hmm. It's easy for the bytes case because the lifetime of the pointer is tied to the bytes object owning the data. I guess it's similar for the memoryview where...

Regarding the build failures, there's a dict in `Builtins.c` that maps the attribute name to the return type. You have to update that as well. OTOH, I don't really see...