Skip to content

Conversation

@0xSris
Copy link

@0xSris 0xSris commented Dec 5, 2025

No description provided.

@Aniketsy
Copy link
Contributor

Requiring Python 3.8+ makes sense. Let’s wait for the maintainers’ decision.

@davidwagner
Copy link
Member

Can you tell me more about the motivation? What is the benefit of this change?

download_url = 'https://github.com/data-8/datascience/archive/%s.zip' % version,
keywords = ['data', 'tools', 'berkeley'],
classifiers = [],
name='datascience',
Copy link
Member

Choose a reason for hiding this comment

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

This seems like a whitespace change that doesn't have any functional effect. We generally discourage unnecessary such changes, if there is no clear benefit.

@0xSris
Copy link
Author

0xSris commented Jan 9, 2026

Python 3.6 has been EOL for a while, so the goal here is to keep the project aligned with currently supported Python versions and reduce legacy maintenance. There’s no urgent bug behind it, it’s mainly a cleanup and modernization change.

@davidwagner
Copy link
Member

Can you help me understand how this reduces legacy maintenance? I have no strong objection, I just don't understand the benefit, and each change that I don't understand introduces some (in this case, small) risk.

@0xSris
Copy link
Author

0xSris commented Jan 12, 2026

Python 3.6 is end-of-life and no longer receives security updates. Many dependencies already require Python 3.8+, so keeping 3.6 adds maintenance and CI overhead. Dropping it simplifies the codebase and aligns the project with currently supported Python versions.

@davidwagner
Copy link
Member

Thanks for the contribution. I don't see any harm to this change and I can see that it might have some incremental value but it doesn't seem to be solving any major problem that I can recognize. I don't perceive any maintenance or CI overhead that this would reduce, and I don't see that the codebase is any simpler after this change. I prefer to make changes only when it's clear that the benefit outweighs the risk, and in this case the benefit seems very small and every change introduces some (in this case, probably very small) risk of breakage. So I'm going to focus on changes with a clearer benefit.

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.

3 participants