Re: [PATCH 0/6] Transition git-p4.py to support Python 3 only

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.