+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.gomm...@gmail.com> wrote: > On Sat, Oct 6, 2018 at 11:24 PM Matti Picus <matti.pi...@gmail.com> wrote: > >> On 05/10/18 11:46, Jerome Kieffer wrote: >> > On Fri, 5 Oct 2018 11:31:20 +0300 >> > Matti Picus <matti.pi...@gmail.com> 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