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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
