Skip to content

Conversation

@ns-rse
Copy link
Contributor

@ns-rse ns-rse commented Jun 3, 2025

Closes #7

Detects Numpy version on the fly and sets the types for float and complex conditional on whether np.__version__ < "2.0.0".

Includes a warning advising users to consider updating them if using an old version of Numpy.

No idea if this is a sensible way of approaching such issues so happy to be advised/guided on better ways of handling such issues.

Closes #7

Detects Numpy version on the fly and sets the types for `float` and `complex` conditional on whether `np.__version__ < "2.0.0"`.

Includes a warning advising users to consider updating them if using an old version of Numpy.

No idea if this is a sensible way of approaching such issues so happy to be advised/guided on better ways of handling such issues.
@hmallen hmallen self-assigned this Jun 9, 2025
Copy link
Owner

@hmallen hmallen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really appreciate the compatibility update. Looks great.

Quick suggestion: For comparing version numbers, you can use the packaging library’s parse_version function instead of just comparing strings. It handles weird cases like pre-releases (for example, "2.0.0rc1") better. For example:

from packaging.version import parse as parse_version

if parse_version(np.__version__) < parse_version("2.0.0"):
    # old types
else:
    # new types

Totally up to you if you want to add it here. I'm happy to merge and make a follow-up change.

Thanks again!

Copy link
Contributor Author

@ns-rse ns-rse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding suggested parse_version() option.

@ns-rse
Copy link
Contributor Author

ns-rse commented Jun 10, 2025

For comparing version numbers, you can use the packaging library’s parse_version function instead of just comparing strings. It handles weird cases like pre-releases (for example, "2.0.0rc1") better.

Thanks @hmallen I wasn't even aware of that library/function but it makes total sense as I hadn't thought about release candidate versions and how they would be handled.

(Lazily) I've committed the suggestions via the PR.

@hmallen
Copy link
Owner

hmallen commented Jun 16, 2025

For comparing version numbers, you can use the packaging library’s parse_version function instead of just comparing strings. It handles weird cases like pre-releases (for example, "2.0.0rc1") better.

Thanks @hmallen I wasn't even aware of that library/function but it makes total sense as I hadn't thought about release candidate versions and how they would be handled.

(Lazily) I've committed the suggestions via the PR.

Thanks a lot for the help! Will merge the changes.

@ns-rse
Copy link
Contributor Author

ns-rse commented Jun 23, 2025

Hi @hmallen

Is there anything else I need to do on this?

@ns-rse

@hmallen
Copy link
Owner

hmallen commented Jun 23, 2025

Hi @hmallen

Is there anything else I need to do on this?

@ns-rse

Sorry for the delay. Think you could add packaging to the install_requires? I think that's all we're missing on this one. I'll have it merged asap.

@hmallen hmallen merged commit 815d266 into hmallen:master Jul 14, 2025
2 checks passed
ns-rse added a commit to AFM-SPM/TopoStats that referenced this pull request Jul 25, 2025
The fix I submitted [upstream](hmallen/numpyencoder#8) to detect the Numpy version being used and handle type deprecation whilst providing backwards compatibility has now been merged.

We can therefore revert to using upstream PyPI released version of `numpyencoder` and remove the use of the forked [AFM-SPM-numpyencoder](https://github.com/AFM-SPM/numpyencoder) version where the same fix had been applied.

This in turn means that releases to PyPI will work again (as you can't release to PyPI when you have dependencies that come from Git repos).
@ns-rse
Copy link
Contributor Author

ns-rse commented Jul 25, 2025

Sorry for missing this, I see it was merged and you've subsequently addressed the required install and migrated to pyproject.toml for configuration too, great work 👍

@hmallen
Copy link
Owner

hmallen commented Aug 4, 2025

Sorry for missing this, I see it was merged and you've subsequently addressed the required install and migrated to pyproject.toml for configuration too, great work 👍

No worries, thanks again for your help along the way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Numpy 2.0 deprecations

2 participants