Should numpy be a required dependency of uncertainties?

[jagerber48]

Inspired by #222

Right now, or at least in the near future, numpy is an optional requirement of uncertainties. Should it be a required dependency? The main reason I ask is because there is a lot of code in uncertainties dedicated to making UFloat play nice with numpy arrays etc. The linked PR also explores the possibility of version incompatibilities between uncertainties and numpy. If numpy is only an optional dependency then I could see issues where some does pip install uncertainties instead of, the more unusual, pip install uncertainties[arrays] and gets a version conflict.

The downside is that numpy is sort of a heavy-weight package so requiring it makes uncertainties less lightweight. Does this matter in practice though? I'm sure the number of people using uncertainties but who want to avoid numpy is very small.

I don't mean this discussion be a discussion about whether we should pin numpy < 2.0 or not (that is already happening in the PR), but, could someone clarify for the me the known issues pip/pypi with setting upper version limits in pyproject.toml?

[andrewgsavage]

I don't think it should be required. There are other array modules than numpy that we may wish to support. Pandas has been trying to make numpy optional for this reason. Id suggest doing something similar to pint using subclassing. Providing proper numpy support (IE not using unumpy) will require adding methods to objects that rely on numpy. Using subclassing allows those methods to be in separate files which don't need to be loaded if numpy isn't installed. I highly recommend looking through pints code to see what I mean. It shares several similarities (wraps numeric objects, formatting, math/numpy ops)

…

On Thu, 16 May 2024, 18:18 Justin Gerber, ***@***.***> wrote: Inspired by #222 <#222> Right now, or at least in the near future, numpy is an optional requirement of uncertainties. Should it be a required dependency? The main reason I ask is because there is a lot of code in uncertainties dedicated to making UFloat play nice with numpy arrays etc. The linked PR also explores the possibility of version incompatibilities between uncertainties and numpy. If numpy is only an optional dependency then I could see issues where some does pip install uncertainties instead of, the more unusual, pip install uncertainties[arrays] and gets a version conflict. The downside is that numpy is sort of a heavy-weight package so requiring it makes uncertainties less lightweight. Does this matter in practice though? I'm sure the number of people using uncertainties but who want to avoid numpy is very small. I don't mean this discussion be a discussion about whether we should pin numpy < 2.0 or not (that is already happening in the PR), but, could someone clarify for the me the known issues pip/pypi with setting upper version limits in pyproject.toml? — Reply to this email directly, view it on GitHub <#227>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEMLEC5TMRX7IPYLHW5NCDZCTS5XAVCNFSM6AAAAABH2UMEX2VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGY3TQMRZHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[newville]

@jagerber48 @andrewgsavage

I think it is fine to leave it as optional. I probably would have guessed that the overlap of "wants to use uncertainties" and "wants to avoid Numpy" is tiny. But, I'm OK with saying that it is non-zero, and so large enough. The basic examples certainly do not require Numpy.

II would also say that uncertainties needs an improved "ndarray-like" wrapping. But we should be mindful of whether that is fully dependent on Numpy or can support other options. Learning more about what pint does for that would be really helpful.