git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Joel Holdsworth <jholdsworth@nvidia.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Luke Diamand <luke@diamand.org>, Git Users <git@vger.kernel.org>
Subject: RE: [PATCH 0/6] Transition git-p4.py to support Python 3 only
Date: Mon, 13 Dec 2021 19:58:23 +0000	[thread overview]
Message-ID: <BN8PR12MB336129AD5C148267925FB387C8749@BN8PR12MB3361.namprd12.prod.outlook.com> (raw)
In-Reply-To: <xmqqv8zsb8xc.fsf@gitster.g>

> Sure, but that defeats the whole notion of "python3 is everywhere,
> python2 is dead, and nobody should be using the 2-year dead version".
> "test_have_prereq PYTHON" should be sufficient in such a world, no?

That's a bit of a stretch.

As Elijah said:

> 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.

Python 3 *is* everywhere. During the transitionary period, Debian allowed python2 and python3 to coexist on a system by giving them the names /usr/bin/python and /usr/bin/python3 respectively, because they are effectively different languages. This allowed legacy code to continue to function in view that it would eventually get ported over to python 3, opting into it by changing the shebang to point at /usr/bin/python3

"test_have_prereq PYTHON" lumps all python versions together as if they were one thing, which they are not. It's as meaningful as lumping together all the Perl versions, or lumping C++98 together with modern C++. If a system has Python 1 installed, strictly speaking the configuration script should indicate that Python is present! - but there's a bit more

I am quite sure the Python 2 will linger on in some form or other - maybe forever, but that doesn't mean the Git project should be developing, maintaining, testing or releasing Python 2 code in 2021.

Python 3 is so well established, that even the minimum version requirement I want to bump to: Python 3.6, is end-of-life.

Joel

      reply	other threads:[~2021-12-13 19:58 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09 20:10 [PATCH 0/6] Transition git-p4.py to support Python 3 only Joel Holdsworth
2021-12-09 20:10 ` [PATCH 1/6] git-p4: Always pass cmd arguments to subprocess as a python lists Joel Holdsworth
2021-12-09 22:42   ` Junio C Hamano
2021-12-09 20:10 ` [PATCH 2/6] git-p4: Don't print shell commands as " Joel Holdsworth
2021-12-09 20:10 ` [PATCH 3/6] git-p4: Removed support for Python 2 Joel Holdsworth
2021-12-09 22:44   ` Junio C Hamano
2021-12-09 23:07     ` rsbecker
2021-12-10  3:25   ` David Aguilar
2021-12-10 10:44     ` Joel Holdsworth
2021-12-09 20:10 ` [PATCH 4/6] git-p4: Decode byte strings before printing Joel Holdsworth
2021-12-09 22:47   ` Junio C Hamano
2021-12-10  8:40     ` Fabian Stelzer
2021-12-10 10:48       ` Joel Holdsworth
2021-12-10 10:41     ` Joel Holdsworth
2021-12-09 20:10 ` [PATCH 5/6] git-p4: Eliminate decode_stream and encode_stream Joel Holdsworth
2021-12-09 20:10 ` [PATCH 6/6] git-p4: Resolve RCS keywords in binary Joel Holdsworth
2021-12-10  7:57   ` Luke Diamand
2021-12-10 10:51     ` Joel Holdsworth
2021-12-10  0:48 ` [PATCH 0/6] Transition git-p4.py to support Python 3 only Ævar Arnfjörð Bjarmason
2021-12-10 10:37   ` Joel Holdsworth
2021-12-10 11:30     ` Ævar Arnfjörð Bjarmason
2021-12-10 21:34   ` Junio C Hamano
2021-12-10 21:53     ` rsbecker
2021-12-11 21:00     ` Elijah Newren
2021-12-12  8:55       ` Luke Diamand
2021-12-10  7:53 ` Luke Diamand
2021-12-10 10:54   ` Joel Holdsworth
2021-12-11  9:58     ` Luke Diamand
2021-12-13 13:47       ` Joel Holdsworth
2021-12-13 19:29         ` Junio C Hamano
2021-12-13 19:58           ` Joel Holdsworth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN8PR12MB336129AD5C148267925FB387C8749@BN8PR12MB3361.namprd12.prod.outlook.com \
    --to=jholdsworth@nvidia.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=luke@diamand.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).