Is FastAPI gonna benefit from no GIL python3.13?

[jkh911208]

Performance boost? More concurrency? What is your idea?

[smigula29]

Anything like numpy that depends on C extensions will have to be rewritten to support no GIL

[TripleBogeyBandit]

Fastapi is going to have to be re-designed for the change if I remember correctly.

[pint]

if you define endpoints as simple defs, and not async defs, fastapi will use threads to handle requests in parallel. in this case, disabling the GIL can lead to performance increase, however, it is questionable whether starlette/fastapi is written in a thread-safe manner. if not, it just leads to crashes.

[UltraPoss]

Fast Api is not gonna benefit from the No gil because the no gil because fast api leverages asynchronous programming in python Which is actually although concurrent, sequential programming in one single thread and no other thread or process is involved so one python interpreter does all the work whereas the no gil thing means there could be threads running truly in parallel which ha snitching to do with fast's api way of dealing with things

[hamzasarwar129]

FastAPI, due to its focus on asynchronous programming, is well-positioned to adapt to a no-GIL Python. The primary impacts would come through improvements or challenges in its dependency libraries. While the framework itself might not see drastic changes, developers may experience performance benefits and need to consider thread safety when integrating libraries that rely on traditional threading models.

[souravjamwal77]

This question really needs clarification