Exposing experimental C-API for DTypes

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Exposing experimental C-API for DTypes

Sebastian Berg
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  

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment