Closed newville closed 2 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 93.20%. Comparing base (
7710da6
) to head (0f23b10
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
so with the new release of asteval
, we can just drop almost all of this and require version 1.0.0 instead?
@reneeotten We could do that. I had been thinking that we should wait for a version or so before requiring "most recent asteval", just in case some packaging systems are not as aggressive at updating packages. But I could be persuaded.
We could merge this, release a Numpy2-compatible version, and then immediately raise an Issue to clean this up ;)
I'll do whichever of those you prefer. a) pin to asteval >= 1.0 and remove most of the changes here b) keep asteval >= 0.9.28, merge this, and give 6 to 9 months before requiring asteval > 1.
FWIW, I decided to tag "asteval 1.0" after years of being stable and then adding in more flexibility for namespaces a year ago. That release "worked" in the sense that within days I was contacted by a group at one of those well-known tech companies that had found some security flaws. I hope to clear those up and push 'asteval 1.0.1' in a week or two.
That's mostly unrelated, but maybe an additional reason to keep lmfit
tied to "very recent asteval".
In my opinion we should just require the latest "asteval" and remove all the changes here that are then bot required anymore. Downstream packagers can easily update asteval to the latest version, it has no dependencies and build very quickly.
@reneeotten OK, requiring asteval>=1.0 does make this all a lot simpler. I would suggest Squash-and-Merge with a modified message, or I could close this and open a new PR with a single commit.
okay, let me take a look later today and I'll squash-merge or do some git voodoo to clean it up.
@newville I clean-up the commits a bit, added the dependency version changes to the documentation and CI, and folded in two more small changes for the latest SciPy/NumPy versions and pre-commit
hooks.
@reneeotten Thanks for cleaning that up and for the maintenance fixes too. I'll merge (not squash) this. I think this warrants releasing version 1.3.2. I'll try to get to that later today or within a few days.
@reneeotten ... except that I am also going to try to fix #960 before 1.3.2 -- but that should be too much of a delay.
Description
This fixes a few problems with NumPy 2.
It fixes #958 by explicitly removing a few odd non-serializable functions if using NumPy2 and a version of asteval that still includes those. That is, this is really a problem with asteval exporting numpy functions that it shouldn't (and are deprecated and not really needed anyway). But, until that is fixed in asteval (in progress), and that version of asteval is required, it is probably safest to look for and remove those offending functions,
This adds
packaging
as a dependency in order to compare versions.This also updates the "latest" variations of the tests to use "numpy>=2.0"
This does not alter the test labeled "development version", but that might be slightly dated.
Type of Changes
Tested on
Python: 3.12.4 | packaged by conda-forge | (main, Jun 17 2024, 10:11:10) [Clang 16.0.6 ]
lmfit: 1.3.1.post1+geee021f6.d20240629, scipy: 1.14.0, numpy: 2.0.0, asteval: 0.9.33, uncertainties: 3.2.1
Verification
Have you