scoder

It's interesting to see that our fstrings implementation apparently got slower between Python 3.10 and 3.12: ``` 2025-03-18 16:10:46 ### Benchmark 'bm_fstrings' (min/median/max): 2025-03-18 16:10:46 Cython 'origin/3.0.x' = 1.121 msec,...

I included the Limited C-API in the benchmark runner to compare against normal Cython. It's currently only enabled for Py3.14.

Turns out that we disabled vectorcall for extension types and builtins back when they didn't support it, and didn't enable it when they started to support it. I found this...

> is [th]is fixed [?] Not all of it. But you should do your own benchmarks to see how Cython 3.1 performs for your specific code.

> This is a very big addition to the limited API & stable ABI. Does it need to be added there? It's functionality that is not otherwise available. Given that...

I'm still writing up the initial implementation in Cython, but so far, ISTM that the `version` passed into `PyMonitoring_EnterScope()` is useless, at least for me. I cannot store it statically...

Another thing that I noticed is that it's unclear how the tracing status and the exception state is managed. Meaning, am I (as a user) expected to disable `tstate->tracing` before...

>> ISTM that the `version` passed into `PyMonitoring_EnterScope()` is useless > > scopes need to be exited and re-entered when the code-like's execution is paused Ah, right. I hadn't looked...

> Adjust our own type inference to avoid it. I suspect this is hard to implement generally. It would only be a heuristic, rarely perfect. It would never beat dedicated...

> strings (`char *`/`cython.p_char`) Python bytes/str objects are actually quite efficient. In comparison, C's `char*` lacks length information and is therefore much more inefficient (and sometimes dangerous) as a replacement.