[Numpy-discussion] Adding a hex version like PY_VERSION_HEX
wieser.eric+numpy at gmail.com
Wed Oct 10 00:03:36 EDT 2018
+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..
On Wed, 10 Oct 2018 at 04:23 Ralf Gommers <ralf.gommers at gmail.com> wrote:
> On Sat, Oct 6, 2018 at 11:24 PM Matti Picus <matti.picus at gmail.com> wrote:
>> On 05/10/18 11:46, Jerome Kieffer wrote:
>> > On Fri, 5 Oct 2018 11:31:20 +0300
>> > Matti Picus <matti.picus at 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?
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion