Exposing experimental C-API for DTypes

Hi all, For DTypes, it may soon make sense to expose API publicly for testing/experimentation. But, right now I don't really want to get roped into discussing API details too much and slowing down potential revamps. Do we have any idea for exposing an "experimental" API? The first option would be "symbols" with an underscore in the name and an understanding that using them might just break if you don't use the exact version you wrote the code for and compiled with (i.e. no API/ABI guarantee). My current expectation is that everyone will be appalled by such a plan... For a single, simple project which would end up as a test, similar to the `rational` tests, we could work in NumPy itself. That is fine, but fairly strictly constrained... Of course I can make a "branch" of NumPy that exports more API, but that doesn't feel great either, it seems a bit clunky. The last idea I have right now is a bit convoluted but safe: We add a private python function: np.core._multiarray_umath.get_new_dtype_api(api_version) and a corresponding header (potentially outside of NumPy). The header would include an: import_new_dtype_api() macro/function that leverages the private "Python" function. To import the API (much like `import_array()` works). Since it would use its own header, it could do strict version checks. And since it would have to "ask numpy", NumPy could require an environment variable to be set and/or print out a warning. Am I missing some obvious solution? Aside from "be patient and get it right the first time"? Cheers, Sebastian
participants (1)
-
Sebastian Berg