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
It's quite easy and cheap to pick the right underlying engine on startup. Much more reasonable for the user to replace rich_posix with rich_uring and understand the difference between POSIX and io_uring backends. I suggest:
Deprecating the rich vs. native distinction.
Auto-selecting between POSIX and io_uring.
It poses a question. If a function is only using built-in Python types, can we avoid the costly 2-layer decorator, and just pass it to the native implementation?
Can you contribute to the implementation?
I can contribute
Is your feature request specific to a certain interface?
Official Python bindings
Contact Details
No response
Is there an existing issue for this?
I have searched the existing issues
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Describe what you are looking for
It's quite easy and cheap to pick the right underlying engine on startup. Much more reasonable for the user to replace
rich_posix
withrich_uring
and understand the difference between POSIX and io_uring backends. I suggest:It poses a question. If a function is only using built-in Python types, can we avoid the costly 2-layer decorator, and just pass it to the native implementation?
Can you contribute to the implementation?
Is your feature request specific to a certain interface?
Official Python bindings
Contact Details
No response
Is there an existing issue for this?
Code of Conduct
The text was updated successfully, but these errors were encountered: