Repository navigation
Drop Python2.7 support #317
Description
Python2.7 will be unsupported in a few months. We should drop Python2.7 before then.
I'm keen to do this as Python2.7 support has long been a headache. If anyone has a good reason to keep Py2.7 support, please make your case in this issue.
Activity
zopyx commentedon Jul 28, 2019
May Python 2.7 rest forever.
No need for further Python 2.7 compatibility.
althonos commentedon Jul 28, 2019
Fine by me, I'm not putting any particular effort for Python 2.7 support right now so I don't care about dropping support.
IMO you should make a last stable release so that all libraries can pin that version more easily in case some devs stuck in the past need to pin anything.
bennr01 commentedon Dec 18, 2019
Small suggestion: dropping py2 support is technically a backwards incompatible api change. When following semantic versioning, this should be indicated by a major version bump.
pyfilesystem2currently has the major version2, which would mean that the next major version would be3. As most of you probably know, a python package ending with3usually indicates py3-only support, which would coincide with the change.This would also allow py2-projects to specify
fs < 3.0.0as a dependency.On the other hand, bumping the major version of a package in a repo called
pyfilesystem2may lead to confusion, so I am not sure whether this change should really be done in accordance with semantic versioning.dargueta commentedon Dec 18, 2019
Package name or package version? I agree with the name.
I do agree that the
2ending has put us in an unfortunate position, but we're going to have to bump the major version at some point. Otherwise we'll be violating the principle of semantic versioning.willmcgugan commentedon Dec 18, 2019
@bennr01 I concur 3.0.0 is the way to go when we drop Python2 support.
The name on Pypy is still
fs. I hope the repos name containing a 2 doesn't confuse too many people. I can always put a note in the readme if it does.odgalvin commentedon Feb 1, 2021
@althonos I could go through and remove the Python 2 compatibility bits if you'd like a PR? Maybe after your next point release. It would tidy up the code a lot.
althonos commentedon Feb 1, 2021
@odgalvin : as Will mentioned, we should make a new repository for that, probably forking this one into PyFilesystem/pyfilesystem3. Plus, it would be great to take advantage of this breaking change to actually address a lot of the breaking issues.
EDIT: I will have more time next week-end to start planning this, and to triage the current PyFilesystem2 issues.
atollk commentedon Mar 24, 2021
Is this an ongoing discussion? Having worked quite a bit on different parts of the
fscode base recently, I agree with @althonos that a chance to perform some breaking changes should be used to clean up as well. I feel like I could chime in with some ideas and would be willing to take up some of the resulting tasks, should we agree on the direction that PyFs3 wants to take.althonos commentedon Mar 25, 2021
@atollk : it's still something i'd like to spend more time on when I can, but not much progress has been done so far, except I started to triage some issues that might be breaking changes.
@willmcgugan : could you add @atollk to the PyFilesystem organization? It would make it easier to discuss and coordinate there.
willmcgugan commentedon Mar 25, 2021
@althonos done
djmattyg007 commentedon Jan 27, 2022
Are there any updates on this? It would be nice to lose the dependency on
six🙏djmattyg007 commentedon Feb 18, 2022
It's also a real issue for making contributions in general, because suddenly I have to care about a language I've literally never used. Working with python2 in any capacity has been a painful experience for a long time, especially since it went EOL over two years ago.
lurch commentedon May 6, 2022
Having just read through this again I agree that this is a backwards-incompatible change and thus (according to the semver rules) warrants a major-version-bump (which coincidentally brings us to 3.0.0), but I don't think that it warrants a new package-name or repo?
willmcgugan commentedon May 6, 2022
I concur that it should warrant a bump to 3, but not a new repo or package.
We could do that at any point really. i.e. we don't need to wait to strip out the 2.7 stuff to declare we don't care about Python 2 compatibility any longer. The work of removing the various 2.7 compatibility fudges could be incremental.
djmattyg007 commentedon May 6, 2022
That probably depends on whether or not you consider the compatibility code to be part of the public interface of the package.
lurch commentedon May 7, 2022
That's why we're doing a major-version-bump. After pyfilesystem 3.0.0 the backwards-compatibility code (for Python2.7) may be removed at any point, and is no longer part of the "supported interface".
edgarrmondragon commentedon Jul 12, 2024
@althonos If I submitted PRs to get package metadata and Python version support up-to-date (drop < 3.8, test with 3.11+) do you think they'd be reviewed and merged?
mcepl commentedon Aug 1, 2024
Last commit two years ago … what do you think?
edgarrmondragon commentedon Aug 2, 2024
No harm in trying :)