Conversation
Co-authored-by: Tom Aldcroft <taldcroft@gmail.com>
Co-authored-by: Tom Aldcroft <taldcroft@gmail.com>
|
@taldcroft @javierggt should we configure this to be backward compatible using numpy version testing? |
|
Tests pass with this version on flight. What happens on flight if the default is not set? |
|
What Tom was suggesting yesterday was to use |
|
Right, Tom was suggesting "astropy.utils.compat.NUMPY_LT_2_0" for use in a different package, but we could use it here. I don't know if it is strictly required that we preserve the copy False behavior for numpy < 2.0 because it wasn't clear to me if numpy was actually managing to do the operation without a copy. But maybe it is lowest impact to just do the if statement. |
|
I am guessing that Tom put that statement there because otherwise it would be copied. This is a performance thing. Unfortunately, no test fails on flight when I remove the line, so I would have to think which case that was intended for. |
|
I have tried a few things to get a test to fail in flight when I remove that statement, and no luck. I don't know what corner case this is meant for. |
|
To be honest I do not recall why I put that there. The upstream default (in astropy In any case, we should not clutter the code with this conditional since tests are currently passing in flight. |
Description
Don't set default of copy=False in
__init__.In numpy > 2 the copy=False default causes an error if the operation cannot be done without a copy. In numpy < 2.0 this was benign as copy=False was equivalent to "copy if you have to". But changing to not set the default appears to be benign in ska with numpy < 2.0 and the astropy Time default was already to not-copy so a change here appears to be non-impacting.
Interface impacts
Testing
Unit tests
Independent check of unit tests by Javier
Functional tests
No functional testing.