GNU bug report logs - #70815
[PATCH] ; Enahnce python-tests.el to adapt different python interpreters

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: kobarity <at> gmail.com, sunlin7.mail <at> gmail.com, mattias.engdegard <at> gmail.com, 70815 <at> debbugs.gnu.org
Subject: bug#70815: [PATCH] ; Enahnce python-tests.el to adapt different python interpreters
Date: Mon, 27 May 2024 14:18:09 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 26 May 2024 16:06:31 -0700
> Cc: mattias.engdegard <at> gmail.com, sunlin7.mail <at> gmail.com, 70815 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think Python 3 should be preferred if the user prefers it.  And if
> > the python interpreter invoked by "python" is not the preferred
> > version, then how can Emacs know which one is the preferred version?
> 
> If we do still care about Python 2, why should we test using only _one_
> version?  If both are available, surely it's better to run the test
> using both.

We do care about Python 2 because some users still use it.  There's no
other reasons: Emacs doesn't care which version of Python is
preferable to the user.

We could test both versions if they are installed, I don't think I'd
mind.

> If we don't want to do that, it makes more sense to prefer Python 3.
> This given that Python 2 is EOL since 4+ years, and is less and less
> likely to be relevant.

Mattias's message in this thread indicates otherwise, I think.

> For example, RHEL 8 will stop offical support for Python 2 next month,
> and RHEL 9 doesn't ship with it.  Debian GNU/Linux has already dropped
> Python 2 from its stable distribution.  And so on.

Emacs doesn't need to follow these tendencies.  We try to avoid
forcing our users to upgrade unrelated or loosely-related software
just because they installed a newer version of Emacs, because forcing
them to do that in many cases ends up sending them down an immense
rabbit hole, whereby upgrading some component requires them to upgrade
many others, in a well-known snowball fashion.  So we generally decide
to drop support for some old software only when keeping it supported
becomes a real burden.

I don't think Python is a maintenance burden for us at this time, is
it?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.