Resolve DeprecationWarnings triggered by tests

[league]

Our tests are hitting a lot of deprecation warnings now, especially in (but not limited to) numpy. This issue can be where we inventory, classify, and discuss resolving them.

[jaycedowell]

From merging of #207 on ubuntu-latest/Python3.10 I see:

• bifrost/DataType.py:51: UserWarning: The NumPy module was reloaded (imported a second time). This can in some cases result in small but subtle issues and is discouraged.
• test/test_block.py:479: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.)
• bifrost/block.py:303: DeprecationWarning: product is deprecated as of NumPy 1.25.0, and will be removed in NumPy 2.0. Please use prod instead.
• bifrost/sigproc2.py", line 366, in read -> self.buf.resize(requested_nbyte)
  ValueError: cannot resize an array that references or is referenced by another array in this way. Use the np.resize function or refcheck=False NB: This one is an error but it doesn't cause problems.
• lint/run.py:219: DeprecationWarning: do_exit is deprecated and it is going to be removed in a future version.
• bifrost/ndarray.py:222: DeprecationWarning: NumPy will stop allowing conversion of out-of-bound Python integers to integer arrays. The conversion of 152 to int8 will fail in the future.

[jaycedowell]

For bifrost/block.py:303 the line number is misleading. It actually looks like the problematic lines are inSplitterBlock.load_settings().

[jaycedowell]

For test/test_block.py:479 I get that next(span_gen).data is a 2D array, making .data[0] a 1D array. Maybe .data.item() for this one?

[jaycedowell]

I was looking through our oh-so-many branches this morning and I found numpy_deprecated_dtypes which might be relevant here. I'm not seeing any of these warnings in CI though.

Update: It's now a PR - #217.

#217 was closed without merging.

[jaycedowell]

I'm looking at bifrost/sigproc2.py:366 to see how self.buf is used. For data with nbit >=8 it isn't; the whole self.buf.resize() thing is only for sub-byte sized data. In that case self.buf directly becomes the data which SigprocFile.read() returns. In light of that maybe a conversion of something like

self.buf = np.resize(self.buf, requested_nbyte)

and

self.buf = np.resize(self.buf, nbyte)

would be the best fix.

[jaycedowell]

There is also #219 now.

[jaycedowell]

With #219 merged it looks like we are down to the numpy.resize thing and the occasional "unrecognized character" that comes from somewhere.