Adding a hex version like PY_VERSION_HEX
In PR 12074 https://github.com/numpy/numpy/pull/12074 I propose adding a function `version.get_numpy_version_as_hex()` which returns a hex value to represent the current NumPy version MAJOR.MINOR.MICRO where v = hex(MAJOR << 24 | MINOR << 16 | MICRO) so the current 1.15.0 would become '0x10f0000'. I also made this avaiable via C through `get_hex_version`. The hex version is based on the |PY_VERSION_HEX| macro from CPython. Currently we have a ABI version and an API version for the numpy C-API. We only increment those for updated or breaking changes in the NumPy C-API, but not for - changes in behavior, especially in python code - changes in sizes of outward-facing structures like PyArray_Desc Occasionally it is desirable to determine backward compatibility from the runtime version, rather than from the ABI or API versions, and having it as a single value makes the comparison in C easy. For instance this may be convenient when there is suspicion that older header files may have been used to create or manipulate an object directly in C (or via a cython optimization), and we want to verify the version used to create the object, or when we may want to verify de-serialized objects. The `numpy.lib._version.NumpyVersion` class enables version comparison in python, but I would prefer a single value that can be stored in a C struct as an integer type. Since this is an enhancement proposal, I am bringing the idea to the mailing list for reactions. Matti
On Fri, 5 Oct 2018 11:31:20 +0300 Matti Picus <matti.picus@gmail.com> wrote:
+1 We use it in our code and it is a good practice, much better then 0.9.0>0.10.0 ! We added some support for dev, alpha, beta, RC and final versions in https://github.com/silx-kit/silx/blob/master/version.py Cheers, -- Jérôme Kieffer
+1 on Ralf's suggestion. I'm not sure there's any case where the C code should be using a hex version number - either it's using the C api, in which case it should just be looking at the C api version - or it's calling back into the python API, in which case it's probably not unreasonable to ask it to inspect `np.__version__` / a hypothetical `sys.version_info`, since it's already going through awkwardness to invoke pure-python APIs.. Eric On Wed, 10 Oct 2018 at 04:23 Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Fri, 5 Oct 2018 11:31:20 +0300 Matti Picus <matti.picus@gmail.com> wrote:
+1 We use it in our code and it is a good practice, much better then 0.9.0>0.10.0 ! We added some support for dev, alpha, beta, RC and final versions in https://github.com/silx-kit/silx/blob/master/version.py Cheers, -- Jérôme Kieffer
+1 on Ralf's suggestion. I'm not sure there's any case where the C code should be using a hex version number - either it's using the C api, in which case it should just be looking at the C api version - or it's calling back into the python API, in which case it's probably not unreasonable to ask it to inspect `np.__version__` / a hypothetical `sys.version_info`, since it's already going through awkwardness to invoke pure-python APIs.. Eric On Wed, 10 Oct 2018 at 04:23 Ralf Gommers <ralf.gommers@gmail.com> wrote:
participants (4)
-
Eric Wieser -
Jerome Kieffer -
Matti Picus -
Ralf Gommers