3 ms·

I feel this way about all wrapper code where someone is like 'okay we need our own internal version of this API'. the reasons vary but are like 'we don't trust

I feel this way about all wrapper code where someone is like 'okay we need our own internal version of this API'. the reasons vary but are like 'we don't trust people to use the official API correctly' (which, fine, but yours is less standard and worse-documented). sometimes the answer is 'we need extra functionality' which, fine, but 1) don't wrap the entire API for gods sake, just add 3 functions, and 2) your codebase over time will end up 99% polyfills point being if you are not using the defaults you are inflicting great misery on whoever inherits your codebase

vitalnodo 2y ago
With such wrappers, it should help to have an interface there to interact with the lower library directly, I think. For example, there is the ziggy-pydust library to write native modules for Python in Zig, and it certainly looks prettier than the usual Python.h import. Still, there is also .ffi to address functions directly that are not yet implemented but are available in Python.h. If such an option is not available, one often wants to replace such a library and prefer the original one. However, even this is in a way a wrapper (a native module), and sometimes it is better to use ctypes directly, for example, for the sake of speed of development.