added utility function to automate data type str generation

[gmabey]

The get_endian_str() function is separate to support my own hack
for generating the string for complex int16 data ...

>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype=float))
'f64_le'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype=complex))
'cf128_le'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype=numpy.uint32))
'u32_le'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype=numpy.uint16))
'u16_le'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype=numpy.complex64))
'cf64_le'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype='>f4'))
'f32_be'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype='=f4'))
'f32_le'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype='<f4'))
'f32_le'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype='<c8'))
'cf64_le'
>>> sigmf.utils.get_data_type_str(numpy.zeros(1, dtype='?'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/s/sigmf/utils.py", line 98, in get_data_type_str
    raise error.SigMFError('Unsupported data type:', atype)
sigmf.error.SigMFError: ('Unsupported data type:', dtype('bool'))

[bhilburn]

This seems like a good useful function. My comments are minor, we should get @Teque5's review.

[bhilburn]

Is this meant to be effectively a catch case where if the endianness is not already defined, it gets set to whatever the current system's endianness is? I don't think I follow the comment on L90

[Teque5]

I think L90 is the case where it gets past L86 & L88.
This should be slightly modified to just if, elif, else and it will make more sense.

[Teque5]

With small changes this is ready to merge.

[Teque5]

I think L90 is the case where it gets past L86 & L88.
This should be slightly modified to just if, elif, else and it will make more sense.

[Teque5]

Remember to add a docstring. Also single letter variables aren't the best. Maybe change it to ray.

[gmabey]

@Teque5 @bhilburn Ok, I think I have now fully integrated that helpful feedback.
Question: I couldn't find in the spec just now whether it's appropriate or not to append _le or _be when the datatype is a single byte. In this case, I've just used whatever the endianness of the system is (the "|" case), but seems to me that the endian suffix could be left off altogether, for the case of single-byte datatypes.

[bhilburn]

@gmabey - You're correct, it can be left off for single byte datatypes, and while the spec provides an example of that, it doesn't explicitly say that. It would be good to clarify that in the spec (that's a note for another PR 😅).

@gmabey - According to Github, it says there is one change requested by @Teque5 that is still unresolved, his comment on L110 regarding the import statement. Do you mind addressing that and pushing, and marking the change as resolved? I think this is then ready to merge 👍

[gmabey]

@bhilburn @Teque5 Forgive my GitHub follies, but I do believe I addressed that issue (the only one I can find is to replace line 110 with from sigmf.utils import get_data_type_str) -- it's definitely there now.

When I try to find and close the change request, I get: "Sometimes commits can disappear after a force-push."

[jacobagilbert]

Thanks @gmabey - two approvals and Ben has given his ✅. Merging.