Re: [Numpy-discussion] Adding a hex version like PY_VERSION_HEX
+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 wrote: > On Sat, Oct 6, 2018 at 11:24 PM Matti Picus wrote: > >> On 05/10/18 11:46, Jerome Kieffer wrote: >> > On Fri, 5 Oct 2018 11:31:20 +0300 >> > Matti Picus wrote: >> > >> >> 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) >> > +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, >> Thanks. I think at this point I will change the proposal to >> >> v = hex(MAJOR << 24 | MINOR << 16 | MICRO << 8) >> >> which leaves room for future enhancement with "release level" and >> "serial" as the lower bits. >> > > Makes sense, but to me adding a tuple (like sys.version_info) would be > more logical. Do that as well or instead of? > > Cheers, > Ralf > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adding a hex version like PY_VERSION_HEX
On Sat, Oct 6, 2018 at 11:24 PM Matti Picus wrote: > On 05/10/18 11:46, Jerome Kieffer wrote: > > On Fri, 5 Oct 2018 11:31:20 +0300 > > Matti Picus wrote: > > > >> 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) > > +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, > Thanks. I think at this point I will change the proposal to > > v = hex(MAJOR << 24 | MINOR << 16 | MICRO << 8) > > which leaves room for future enhancement with "release level" and "serial" > as the lower bits. > Makes sense, but to me adding a tuple (like sys.version_info) would be more logical. Do that as well or instead of? Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adding a hex version like PY_VERSION_HEX
On 05/10/18 11:46, Jerome Kieffer wrote: On Fri, 5 Oct 2018 11:31:20 +0300 Matti Picus wrote: 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) +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, Thanks. I think at this point I will change the proposal to v = hex(MAJOR << 24 | MINOR << 16 | MICRO << 8) which leaves room for future enhancement with "release level" and "serial" as the lower bits. Matti ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adding a hex version like PY_VERSION_HEX
On Fri, 5 Oct 2018 11:31:20 +0300 Matti Picus wrote: > 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) +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 ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 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 '0x10f'. 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 ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
