On Thu, Dec 09 2021, Joel Holdsworth wrote: > Python 2 was discontinued in 2020, and there is no longer any officially > supported interpreter. Further development of git-p4.py will require > would-be developers to test their changes with all supported dialects of > the language. However, if there is no longer any supported runtime > environment available, this places an unreasonable burden on the Git > project to maintain support for an obselete dialect of the language. Does it? I can still install Python 2.7 on Debian, presumably other OS's have similar ways to easily test it. I'm not that familiar with our python integration and have never used git-py, but I found this series hard to read through. You've got [12]/6 which don't make it clear whether they're needed for python3, or are some mixture of requirenments and a matter of taste (or a newer API?). E.g. isn't the formatting you're changing in 2/6 supported in Python3? Then for 1/6 "pass cmd arguments to subprocess as a python lists" if it's not just a matter of taste can we lead with a narrow change to the new API (presumably we can pass to our own function as a string, split on whitespace, and then pass to whatever python API executes it as a list first. Some of these changes also just seem to be entirely unrelated refactorings, e.g. 6/6 where you're changing a multi-line commented regexp into something that's a dense one-liner. Does Python 3 not support the equivalent of Perl's /x, or is something else going on here? You then change the requirenment not to python 3.0, but 3.7, which AFAICT was released a couple of years ago. We tend to try to capture some of the oldest LTS OS's in common use, e.g. the last 2-3 RHEL releases. We still "support" Perl 5.8, which was released in 2002 (although that could probably do with a version bump, but not to a release to 2018). I'm not at all opposed to this Python version bump, I truly don't know enough to know if it's a good change. Maybe we can/should also be more aggressive with a version dependency with git-p4 than with something more central to git like perl or curl. The commit messages could just really use some extra hand-holding and explanation, and a clear split-out of things related to the version bump v.s. things not needed for that, or unrelated refactorings.
