Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python deprecation cycle #2836

Open
h-mayorquin opened this issue May 12, 2024 · 5 comments
Open

Python deprecation cycle #2836

h-mayorquin opened this issue May 12, 2024 · 5 comments
Labels
discussion General discussions and community feedback packaging Related to packaging/style

Comments

@h-mayorquin
Copy link
Collaborator

Python 3.8 is coming to its EOL in September.

https://devguide.python.org/versions/

However, I want to make you aware that numpy follows a different cycle and within that python 3.8 already got deprecated

https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table

I wanted to discuss how to handle this. I think given the centrality for this package and neo we should probably follow numpy cycle instead of the longer python one.

What do you think?

@h-mayorquin h-mayorquin added packaging Related to packaging/style discussion General discussions and community feedback labels May 12, 2024
@zm711
Copy link
Collaborator

zm711 commented May 12, 2024

Neo supports older numpy versions than the actual numpy EOL cycle. (It still tests 3.8 against 1.20.x). So if we go based on neo then it would basically still just be following the python release cycle.

@h-mayorquin
Copy link
Collaborator Author

Numpy 1.20 has been deprecated for a year:
https://numpy.org/neps/nep-0029-deprecation_policy.html

Maybe something to discuss at neo. Any reason you guys are testing for that?

@zm711
Copy link
Collaborator

zm711 commented May 13, 2024

I think the idea was that numpy does end of life pretty quick so as long as tests pass with it then it can be supported for longer (ie until the python version goes end of life).

@JoeZiminski
Copy link
Contributor

We follow the Numpy deprecation cycle for the same reason. I think it makes sense as it is a core module. Another benefit is that it is very easy to forget about python deprecation cycles, and so at least if there is a few months delay before you remember, you are still not behind the actual python deprecation.

@h-mayorquin
Copy link
Collaborator Author

As a data point that presents evidence against my preference (following numpy deprecation cycle) today someone asked me if they could run the the library in python 3.7 (already deprecated for a while!) because of gpu issues (old nvida gpu I guess).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion General discussions and community feedback packaging Related to packaging/style
Projects
None yet
Development

No branches or pull requests

3 participants