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

From: Elijah Newren <newren@gmail.com>
Date: Dec 11, 2021, 21:00 UTC
Message-ID: <CABPp-BHjc1i4o-Oe2U2fV8_TRgRPfve_mYt=kveTYMy-3BdpCA@mail.gmail.com>
In-Reply-To: <xmqqsfv0m9f5.fsf@gitster.g>

Hi,

On Fri, Dec 10, 2021 at 10:07 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 18 quoted lines

>
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > 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.
>
> Yes, that is a good point to make against "we cannot maintain the
> half meant to cater to Python2 of the script".  Developers should be
> able to keep and test Python2 support, if it is necessary.

I also disagree with the reason Joel gave in the quoted paragraph for dropping Python2 support, but I think there are other good reasons to drop it.

Show 5 quoted lines

> So the more important question is if there are end-users that have
> no choice but sticking to Python2.  Is there distributions and
> systems that do not offer Python3, on which end-users have happily
> been using Python2?  If some users with vendor supported Python2 do
> not have access to Python3, cutting them off may be premature.

These are good questions, though I think there's more to it than this, as I'll mention in just a minute...

> As the general direction, I do not mind deprecating support for
> Python2, and then eventually removing it.  I just do not know if 2
> years is long enough for the latter (IIRC, the sunset happened at
> the beginning of 2020, and we are about to end 2021).

Python2 was deprecated by the python project in 2008, with announced plans to stop all support (including security fixes) in 2015. They pushed the sunset date back to Jan 1, 2020. So it has only been end-of-life for just under 2 years, but it's been deprecated for over 13 years.

In regards to your good questions about Python3 availability on some platforms: If such platforms exist, they have had over a decade's heads up...so let's ask a few extra questions. If these platforms still haven't made python3 available, would newer versions of Git even be available on these platforms? Even if newer Git versions are available, would users on such platforms have any qualms with using an older Git version given the platform insistence of only providing an old Python version lacking any support (even security fixes)?

Some of my personal python2/python3 experience, if it's useful in weighing decisions:

* There are python projects for which I still continue to support
simultaneous python2 and python3 usage, though for projects that are
smaller then git-p4.py (e.g. 1/2 to 1/3 the size).  Such multi-version
support is painful, and it causes occasional bugs that hit users that
wouldn't arise if there was only one supported python version.

* I initially wanted to also do the multi-version support for
git-filter-repo (which is approximately the same size as git-p4.py,
and obviously also interfaces with git somewhat deeply).  I gave up on
it, and didn't consider it justified, especially with the
then-soon-impending End-Of-Life for python2.  I instead just switched
from python2 -> python3 (in 2019; yes, I'm a straggler.)  Granted, I
did benefit from the fact that git-filter-repo is a
once-in-a-blue-moon usage tool (and only by one member on the team),
rather than a daily usage tool, but I may have come to the same
decision anyway even back then.

* (Slight tangent) I tried to use unicode strings everywhere in
git-filter-repo a few times, but invariably found it to be buggy and
slow.  It was a mistake, and I eventually switched over to bytestrings
everywhere, only converting to unicode (when possible) when printing
messages for the user on the console.  bytestrings are ugly to use
(IMO), but they're a better data model when dealing with file
contents, process output, filenames, etc.  I think git-p4's decision
to attempt to use unicode strings everywhere is a mistake that'll
probably result in bugs based on that experience of mine; it's not an
appropriate model of the relevant data.  It'll also make things
slower.

[I actually think the unicode vs. bytestring thing might be more important for bug fixing than limiting to python3. Though I think both are worthwhile.]