GNU bug report logs -
#70815
[PATCH] ; Enahnce python-tests.el to adapt different python interpreters
Previous Next
Reported by: Lin Sun <sunlin7.mail <at> gmail.com>
Date: Tue, 7 May 2024 06:54:02 UTC
Severity: normal
Tags: patch
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70815 in the body.
You can then email your comments to 70815 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Tue, 07 May 2024 06:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lin Sun <sunlin7.mail <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 07 May 2024 06:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
The python-tests.el will fail on finding interpreter "python" for
there is no "python" on CentOS8, Ubuntu 20.04, only "python3" exists
after installation.
And the patch will try to search python/python3/python2 as the python
testing interpreter; it also support a env var
"EMACS_PYTHON_INTERPRETER" to switch between different version of
python (eg: python3.6, python3.11, ...).
Please help review the enhancement in "python-tests.el". Thanks.
[0001-Enahnce-python-tests.el-to-adapt-different-python-in.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sat, 11 May 2024 09:06:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 70815 <at> debbugs.gnu.org (full text, mbox):
> From: Lin Sun <sunlin7.mail <at> gmail.com>
> Date: Tue, 7 May 2024 06:53:05 +0000
>
> The python-tests.el will fail on finding interpreter "python" for
> there is no "python" on CentOS8, Ubuntu 20.04, only "python3" exists
> after installation.
Thanks, I have some comments, and maybe kobarity will have as well.
> +(defun python-tests-get-shell-interpreter (&optional refresh)
AFAICT, this function is never called with the optional REFRESH
argument non-nil, so why do we need it?
> + (if (and python-tests-shell-interpreter (null refresh))
> + python-tests-shell-interpreter
> + (setq python-tests-shell-interpreter
> + (or (when-let* ((interpreter (getenv "EMACS_PYTHON_INTERPRETER")))
> + (or (executable-find interpreter)
> + (error "Not found EMACS_PYTHON_INTERPRETER: %s" interpreter)))
Is it indeed useful to error out here? Should we instead fall back to
the default list, '("python" "python3" "python2") ?
> + (cl-some #'executable-find '("python" "python3" "python2"))))))
cl-some is in cl-extra, so the test should require it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sat, 11 May 2024 13:39:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>
> > From: Lin Sun <sunlin7.mail <at> gmail.com>
> > Date: Tue, 7 May 2024 06:53:05 +0000
> >
> > The python-tests.el will fail on finding interpreter "python" for
> > there is no "python" on CentOS8, Ubuntu 20.04, only "python3" exists
> > after installation.
>
> Thanks, I have some comments, and maybe kobarity will have as well.
Hi Lin,
Please correct the typo "Enahnce" in the title.
I think the summary line of this commit should not begin with a
semicolon. CONTRIBUTE says:
If the summary line starts with a semicolon and a space "; ", the
commit message will be skipped and not added to the generated
ChangeLog file. Use this for minor commits that do not need to be
mentioned in the ChangeLog file, such as changes in etc/NEWS, typo
fixes, etc.
When revising the patch, please include the bug number. CONTRIBUTE
says:
- The commit message should contain "Bug#NNNNN" if it is related to
bug number NNNNN in the debbugs database. This string is often
parenthesized, as in "(Bug#19003)".
python-tests-get-shell-interpreter should have an docstring. This can
be checked with checkdoc. CONTRIBUTE says:
Use 'checkdoc' to check for documentation errors before submitting a
patch.
I recommend to use Flymake or Flycheck. There are many violations in
python-tests.el, but I think it is better for new patches to follow
this rule.
when-let* used in python-tests-get-shell-interpreter could be replaced
with when-let.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sat, 11 May 2024 14:29:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, May 11, 2024, 06:37 kobarity <kobarity <at> gmail.com> wrote:
>
> Eli Zaretskii wrote:
> >
> > > From: Lin Sun <sunlin7.mail <at> gmail.com>
> > > Date: Tue, 7 May 2024 06:53:05 +0000
> > >
> > > The python-tests.el will fail on finding interpreter "python" for
> > > there is no "python" on CentOS8, Ubuntu 20.04, only "python3" exists
> > > after installation.
> >
> > Thanks, I have some comments, and maybe kobarity will have as well.
>
> Hi Lin,
>
> Please correct the typo "Enahnce" in the title.
>
> I think the summary line of this commit should not begin with a
> semicolon. CONTRIBUTE says:
>
> If the summary line starts with a semicolon and a space "; ", the
> commit message will be skipped and not added to the generated
> ChangeLog file. Use this for minor commits that do not need to be
> mentioned in the ChangeLog file, such as changes in etc/NEWS, typo
> fixes, etc.
>
> When revising the patch, please include the bug number. CONTRIBUTE
> says:
>
> - The commit message should contain "Bug#NNNNN" if it is related to
> bug number NNNNN in the debbugs database. This string is often
> parenthesized, as in "(Bug#19003)".
>
> python-tests-get-shell-interpreter should have an docstring. This can
> be checked with checkdoc. CONTRIBUTE says:
>
> Use 'checkdoc' to check for documentation errors before submitting a
> patch.
>
> I recommend to use Flymake or Flycheck. There are many violations in
> python-tests.el, but I think it is better for new patches to follow
> this rule.
>
> when-let* used in python-tests-get-shell-interpreter could be replaced
> with when-let.
>
Hi Eli, kobarit,
I'm trying change the code to follow your comments, will update later,
thank you!
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 12 May 2024 02:08:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Lin Sun wrote:
> On Sat, May 11, 2024, 06:37 kobarity <kobarity <at> gmail.com> wrote:
>
> Eli Zaretskii wrote:
> >
> > > From: Lin Sun <sunlin7.mail <at> gmail.com>
> > > Date: Tue, 7 May 2024 06:53:05 +0000
> > >
> > > The python-tests.el will fail on finding interpreter "python" for
> > > there is no "python" on CentOS8, Ubuntu 20.04, only "python3" exists
> > > after installation.
> >
> > Thanks, I have some comments, and maybe kobarity will have as well.
>
> Hi Lin,
>
> Please correct the typo "Enahnce" in the title.
>
> I think the summary line of this commit should not begin with a
> semicolon. CONTRIBUTE says:
>
> If the summary line starts with a semicolon and a space "; ", the
> commit message will be skipped and not added to the generated
> ChangeLog file. Use this for minor commits that do not need to be
> mentioned in the ChangeLog file, such as changes in etc/NEWS, typo
> fixes, etc.
>
> When revising the patch, please include the bug number. CONTRIBUTE
> says:
>
> - The commit message should contain "Bug#NNNNN" if it is related to
> bug number NNNNN in the debbugs database. This string is often
> parenthesized, as in "(Bug#19003)".
>
> python-tests-get-shell-interpreter should have an docstring. This can
> be checked with checkdoc. CONTRIBUTE says:
>
> Use 'checkdoc' to check for documentation errors before submitting a
> patch.
>
> I recommend to use Flymake or Flycheck. There are many violations in
> python-tests.el, but I think it is better for new patches to follow
> this rule.
>
> when-let* used in python-tests-get-shell-interpreter could be replaced
> with when-let.
>
> Hi Eli, kobarit,
> I'm trying change the code to follow your comments, will update later, thank you!
Hi Lin,
I noticed another issue. If there is only python2 in the PATH and no
python or python3, some tests will fail.
20 unexpected results:
FAILED python-completion-at-point-1
FAILED python-completion-at-point-2
FAILED python-completion-at-point-native-1
FAILED python-completion-at-point-native-2
FAILED python-completion-at-point-native-with-eldoc-1
FAILED python-completion-at-point-native-with-ffap-1
FAILED python-completion-at-point-pdb-1
FAILED python-completion-at-point-while-running-1
FAILED python-eldoc--get-doc-at-point-1
FAILED python-eldoc--get-doc-at-point-while-running-1
FAILED python-ffap-module-path-1
FAILED python-ffap-module-path-while-running-1
FAILED python-shell-completion-at-point-1
FAILED python-shell-completion-at-point-jedi-completer
FAILED python-shell-completion-at-point-native-1
FAILED python-shell-prompt-detect-1
FAILED python-shell-prompt-detect-2
FAILED python-shell-prompt-set-calculated-regexps-6
FAILED python-test--shell-send-block
FAILED python-tests--run-python-selects-window
This is because `python-shell-interpreter' is not let-bound and is set
to "python3".
One way to resolve these would be to provide a thin wrapper like
`python-tests-shell-with-shell-buffer' and bind
`python-shell-interpreter' to (python-tests-get-shell-interpreter).
Current ERTs seem to support both Python 2/3, but it may become
necessary to write an ERT that supports only Python 3. It would be
nice if the author of the ERT could specify an interpreter, but there
may be no need to prepare one now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sat, 18 May 2024 22:22:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Lin Sun <sunlin7.mail <at> gmail.com> writes:
> From 49dfcecbbffaf15aa0414d15f22d8bcbf768ebb3 Mon Sep 17 00:00:00 2001
> From: Lin Sun <sunlin7 <at> hotmail.com>
> Date: Fri, 3 May 2024 06:52:22 +0000
> Subject: [PATCH] ; Enahnce python-tests.el to adapt different python
> interpreters
>
> * test/lisp/progmodes/python-tests.el
> (python-tests-get-shell-interpreter): New function to get python
> interpreter for testing.
> ---
> test/lisp/progmodes/python-tests.el | 87 ++++++++++++++++-------------
> 1 file changed, 48 insertions(+), 39 deletions(-)
>
> diff --git a/test/lisp/progmodes/python-tests.el b/test/lisp/progmodes/python-tests.el
> index f50797953c3..6da149925ec 100644
> --- a/test/lisp/progmodes/python-tests.el
> +++ b/test/lisp/progmodes/python-tests.el
> @@ -3718,7 +3718,16 @@ if x:
>
> ;;; Shell integration
>
> -(defvar python-tests-shell-interpreter "python")
> +(defvar python-tests-shell-interpreter nil)
> +
> +(defun python-tests-get-shell-interpreter (&optional refresh)
> + (if (and python-tests-shell-interpreter (null refresh))
> + python-tests-shell-interpreter
> + (setq python-tests-shell-interpreter
> + (or (when-let* ((interpreter (getenv "EMACS_PYTHON_INTERPRETER")))
> + (or (executable-find interpreter)
> + (error "Not found EMACS_PYTHON_INTERPRETER: %s" interpreter)))
> + (cl-some #'executable-find '("python" "python3" "python2"))))))
It makes sense to look for "python3", but is it really useful to look
for "python2" at this point?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 19 May 2024 05:55:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 70815 <at> debbugs.gnu.org (full text, mbox):
> Cc: kobarity <kobarity <at> gmail.com>
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sat, 18 May 2024 22:20:44 +0000
>
> It makes sense to look for "python3", but is it really useful to look
> for "python2" at this point?
I don't think we want to drop Python 2.x support, not yet.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 20 May 2024 00:10:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I attached the latest patch, hope it resolved all your concerns.
> If there is only python2 in the PATH and no python or python3, some tests will fail.
It's caused by the python.el didn't search "python2", so it may need
another patch to change python.el.
[0001-Enahnce-python-tests.el-to-adapt-different-python-in.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 20 May 2024 15:55:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii wrote:
> > Cc: kobarity <kobarity <at> gmail.com>
> > From: Stefan Kangas <stefankangas <at> gmail.com>
> > Date: Sat, 18 May 2024 22:20:44 +0000
> >
> > It makes sense to look for "python3", but is it really useful to look
> > for "python2" at this point?
> I don't think we want to drop Python 2.x support, not yet.
I don't want to drop Python 2 support either, but I don't think the
addition of the "python2" command is mandatory. As the current master
does not run the "python2" command either. However, I don't think it
is a bad idea to add the "python2" command.
Lin Sun wrote:
> Hi,
> I attached the latest patch, hope it resolved all your concerns.
Hi Lin,
There is still a typo "Enahnce" in the summary line, and there is a
typo in the docstring of `python-tests-get-shell-interpreter' as well.
> > If there is only python2 in the PATH and no python or python3, some tests will fail.
> It's caused by the python.el didn't search "python2", so it may need
> another patch to change python.el.
I don't think so. Attached is a diff to your patch to resolve this
issue. It let-binds `python-shell-interpreter' in some ERTs. It
also includes the fix of the typo in the docstring of
`python-tests-get-shell-interpreter'.
Without these modifications, EMACS_PYTHON_INTERPRETER will not work as
expected either on those ERTs.
As for EMACS_PYTHON_INTERPRETER, I am a little doubtful that it is the
right thing to introduce. It allows the ERT runner to specify the
interpreter. It's OK for ERTs that can be run on both Python 2 and 3,
but you may want to write an ERT that can only be run on Python 3.
[fix-70815.diff (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 20 May 2024 17:53:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, May 20, 2024 at 3:53 PM kobarity <kobarity <at> gmail.com> wrote:
> Eli Zaretskii wrote:
> > > Cc: kobarity <kobarity <at> gmail.com>
> > > From: Stefan Kangas <stefankangas <at> gmail.com>
> > > Date: Sat, 18 May 2024 22:20:44 +0000
> > >
> > > It makes sense to look for "python3", but is it really useful to look
> > > for "python2" at this point?
> > I don't think we want to drop Python 2.x support, not yet.
>
> I don't want to drop Python 2 support either, but I don't think the
> addition of the "python2" command is mandatory. As the current master
> does not run the "python2" command either. However, I don't think it
> is a bad idea to add the "python2" command.
>
> Lin Sun wrote:
> > Hi,
> > I attached the latest patch, hope it resolved all your concerns.
>
> Hi Lin,
> There is still a typo "Enahnce" in the summary line, and there is a
> typo in the docstring of `python-tests-get-shell-interpreter' as well.
>
> > > If there is only python2 in the PATH and no python or python3, some tests will fail.
> > It's caused by the python.el didn't search "python2", so it may need
> > another patch to change python.el.
>
> I don't think so. Attached is a diff to your patch to resolve this
> issue. It let-binds `python-shell-interpreter' in some ERTs. It
> also includes the fix of the typo in the docstring of
> `python-tests-get-shell-interpreter'.
>
> Without these modifications, EMACS_PYTHON_INTERPRETER will not work as
> expected either on those ERTs.
>
> As for EMACS_PYTHON_INTERPRETER, I am a little doubtful that it is the
> right thing to introduce. It allows the ERT runner to specify the
> interpreter. It's OK for ERTs that can be run on both Python 2 and 3,
> but you may want to write an ERT that can only be run on Python 3.
Thank you for the comments, now get your points and agree with you.
I merged your patch together, also corrected the typo in the commit message.
Please help review the attached patch. Thank you !
[0001-Enhance-python-tests.el-to-adapt-different-python-in.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Tue, 21 May 2024 14:06:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lin Sun wrote:
> On Mon, May 20, 2024 at 3:53 PM kobarity <kobarity <at> gmail.com> wrote:
> > Eli Zaretskii wrote:
> > > > Cc: kobarity <kobarity <at> gmail.com>
> > > > From: Stefan Kangas <stefankangas <at> gmail.com>
> > > > Date: Sat, 18 May 2024 22:20:44 +0000
> > > >
> > > > It makes sense to look for "python3", but is it really useful to look
> > > > for "python2" at this point?
> > > I don't think we want to drop Python 2.x support, not yet.
> >
> > I don't want to drop Python 2 support either, but I don't think the
> > addition of the "python2" command is mandatory. As the current master
> > does not run the "python2" command either. However, I don't think it
> > is a bad idea to add the "python2" command.
> >
> > Lin Sun wrote:
> > > Hi,
> > > I attached the latest patch, hope it resolved all your concerns.
> >
> > Hi Lin,
> > There is still a typo "Enahnce" in the summary line, and there is a
> > typo in the docstring of `python-tests-get-shell-interpreter' as well.
> >
> > > > If there is only python2 in the PATH and no python or python3, some tests will fail.
> > > It's caused by the python.el didn't search "python2", so it may need
> > > another patch to change python.el.
> >
> > I don't think so. Attached is a diff to your patch to resolve this
> > issue. It let-binds `python-shell-interpreter' in some ERTs. It
> > also includes the fix of the typo in the docstring of
> > `python-tests-get-shell-interpreter'.
> >
> > Without these modifications, EMACS_PYTHON_INTERPRETER will not work as
> > expected either on those ERTs.
> >
> > As for EMACS_PYTHON_INTERPRETER, I am a little doubtful that it is the
> > right thing to introduce. It allows the ERT runner to specify the
> > interpreter. It's OK for ERTs that can be run on both Python 2 and 3,
> > but you may want to write an ERT that can only be run on Python 3.
>
> Thank you for the comments, now get your points and agree with you.
> I merged your patch together, also corrected the typo in the commit message.
> Please help review the attached patch. Thank you !
Sorry, there was a problem in my diff. Two tests fail when
EMACS_PYTHON_INTERPRETER is not found. Please apply the attached
diff. It also includes a suggestion for improving the error message.
Please consider.
[fix-70815-2.diff (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Tue, 21 May 2024 15:36:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, May 21, 2024 at 2:04 PM kobarity <kobarity <at> gmail.com> wrote:
>
>
> Lin Sun wrote:
> > On Mon, May 20, 2024 at 3:53 PM kobarity <kobarity <at> gmail.com> wrote:
> > > Eli Zaretskii wrote:
> > > > > Cc: kobarity <kobarity <at> gmail.com>
> > > > > From: Stefan Kangas <stefankangas <at> gmail.com>
> > > > > Date: Sat, 18 May 2024 22:20:44 +0000
> > > > >
> > > > > It makes sense to look for "python3", but is it really useful to look
> > > > > for "python2" at this point?
> > > > I don't think we want to drop Python 2.x support, not yet.
> > >
> > > I don't want to drop Python 2 support either, but I don't think the
> > > addition of the "python2" command is mandatory. As the current master
> > > does not run the "python2" command either. However, I don't think it
> > > is a bad idea to add the "python2" command.
> > >
> > > Lin Sun wrote:
> > > > Hi,
> > > > I attached the latest patch, hope it resolved all your concerns.
> > >
> > > Hi Lin,
> > > There is still a typo "Enahnce" in the summary line, and there is a
> > > typo in the docstring of `python-tests-get-shell-interpreter' as well.
> > >
> > > > > If there is only python2 in the PATH and no python or python3, some tests will fail.
> > > > It's caused by the python.el didn't search "python2", so it may need
> > > > another patch to change python.el.
> > >
> > > I don't think so. Attached is a diff to your patch to resolve this
> > > issue. It let-binds `python-shell-interpreter' in some ERTs. It
> > > also includes the fix of the typo in the docstring of
> > > `python-tests-get-shell-interpreter'.
> > >
> > > Without these modifications, EMACS_PYTHON_INTERPRETER will not work as
> > > expected either on those ERTs.
> > >
> > > As for EMACS_PYTHON_INTERPRETER, I am a little doubtful that it is the
> > > right thing to introduce. It allows the ERT runner to specify the
> > > interpreter. It's OK for ERTs that can be run on both Python 2 and 3,
> > > but you may want to write an ERT that can only be run on Python 3.
> >
> > Thank you for the comments, now get your points and agree with you.
> > I merged your patch together, also corrected the typo in the commit message.
> > Please help review the attached patch. Thank you !
>
> Sorry, there was a problem in my diff. Two tests fail when
> EMACS_PYTHON_INTERPRETER is not found. Please apply the attached
> diff. It also includes a suggestion for improving the error message.
> Please consider.
Merged your changes and tested on my local (with python/python3), it
works perfectly. Thank you.
And the patch file is attached .
[0001-Enhance-python-tests.el-to-adapt-different-python-in.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Wed, 22 May 2024 14:40:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Lin Sun wrote:
> On Tue, May 21, 2024 at 2:04 PM kobarity <kobarity <at> gmail.com> wrote:
> >
> >
> > Lin Sun wrote:
> > > On Mon, May 20, 2024 at 3:53 PM kobarity <kobarity <at> gmail.com> wrote:
> > > > Eli Zaretskii wrote:
> > > > > > Cc: kobarity <kobarity <at> gmail.com>
> > > > > > From: Stefan Kangas <stefankangas <at> gmail.com>
> > > > > > Date: Sat, 18 May 2024 22:20:44 +0000
> > > > > >
> > > > > > It makes sense to look for "python3", but is it really useful to look
> > > > > > for "python2" at this point?
> > > > > I don't think we want to drop Python 2.x support, not yet.
> > > >
> > > > I don't want to drop Python 2 support either, but I don't think the
> > > > addition of the "python2" command is mandatory. As the current master
> > > > does not run the "python2" command either. However, I don't think it
> > > > is a bad idea to add the "python2" command.
> > > >
> > > > Lin Sun wrote:
> > > > > Hi,
> > > > > I attached the latest patch, hope it resolved all your concerns.
> > > >
> > > > Hi Lin,
> > > > There is still a typo "Enahnce" in the summary line, and there is a
> > > > typo in the docstring of `python-tests-get-shell-interpreter' as well.
> > > >
> > > > > > If there is only python2 in the PATH and no python or python3, some tests will fail.
> > > > > It's caused by the python.el didn't search "python2", so it may need
> > > > > another patch to change python.el.
> > > >
> > > > I don't think so. Attached is a diff to your patch to resolve this
> > > > issue. It let-binds `python-shell-interpreter' in some ERTs. It
> > > > also includes the fix of the typo in the docstring of
> > > > `python-tests-get-shell-interpreter'.
> > > >
> > > > Without these modifications, EMACS_PYTHON_INTERPRETER will not work as
> > > > expected either on those ERTs.
> > > >
> > > > As for EMACS_PYTHON_INTERPRETER, I am a little doubtful that it is the
> > > > right thing to introduce. It allows the ERT runner to specify the
> > > > interpreter. It's OK for ERTs that can be run on both Python 2 and 3,
> > > > but you may want to write an ERT that can only be run on Python 3.
> > >
> > > Thank you for the comments, now get your points and agree with you.
> > > I merged your patch together, also corrected the typo in the commit message.
> > > Please help review the attached patch. Thank you !
> >
> > Sorry, there was a problem in my diff. Two tests fail when
> > EMACS_PYTHON_INTERPRETER is not found. Please apply the attached
> > diff. It also includes a suggestion for improving the error message.
> > Please consider.
>
> Merged your changes and tested on my local (with python/python3), it
> works perfectly. Thank you.
>
> And the patch file is attached .
Thanks, it looks good to me.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Thu, 23 May 2024 13:10:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Lin Sun <sunlin7.mail <at> gmail.com>:
bug acknowledged by developer.
(Thu, 23 May 2024 13:10:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 70815-done <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 22 May 2024 23:38:02 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> Stefan Kangas <stefankangas <at> gmail.com>,
> 70815 <at> debbugs.gnu.org
>
>
> Lin Sun wrote:
> > On Tue, May 21, 2024 at 2:04 PM kobarity <kobarity <at> gmail.com> wrote:
> > >
> > >
> > > Lin Sun wrote:
> > > > On Mon, May 20, 2024 at 3:53 PM kobarity <kobarity <at> gmail.com> wrote:
> > > > > Eli Zaretskii wrote:
> > > > > > > Cc: kobarity <kobarity <at> gmail.com>
> > > > > > > From: Stefan Kangas <stefankangas <at> gmail.com>
> > > > > > > Date: Sat, 18 May 2024 22:20:44 +0000
> > > > > > >
> > > > > > > It makes sense to look for "python3", but is it really useful to look
> > > > > > > for "python2" at this point?
> > > > > > I don't think we want to drop Python 2.x support, not yet.
> > > > >
> > > > > I don't want to drop Python 2 support either, but I don't think the
> > > > > addition of the "python2" command is mandatory. As the current master
> > > > > does not run the "python2" command either. However, I don't think it
> > > > > is a bad idea to add the "python2" command.
> > > > >
> > > > > Lin Sun wrote:
> > > > > > Hi,
> > > > > > I attached the latest patch, hope it resolved all your concerns.
> > > > >
> > > > > Hi Lin,
> > > > > There is still a typo "Enahnce" in the summary line, and there is a
> > > > > typo in the docstring of `python-tests-get-shell-interpreter' as well.
> > > > >
> > > > > > > If there is only python2 in the PATH and no python or python3, some tests will fail.
> > > > > > It's caused by the python.el didn't search "python2", so it may need
> > > > > > another patch to change python.el.
> > > > >
> > > > > I don't think so. Attached is a diff to your patch to resolve this
> > > > > issue. It let-binds `python-shell-interpreter' in some ERTs. It
> > > > > also includes the fix of the typo in the docstring of
> > > > > `python-tests-get-shell-interpreter'.
> > > > >
> > > > > Without these modifications, EMACS_PYTHON_INTERPRETER will not work as
> > > > > expected either on those ERTs.
> > > > >
> > > > > As for EMACS_PYTHON_INTERPRETER, I am a little doubtful that it is the
> > > > > right thing to introduce. It allows the ERT runner to specify the
> > > > > interpreter. It's OK for ERTs that can be run on both Python 2 and 3,
> > > > > but you may want to write an ERT that can only be run on Python 3.
> > > >
> > > > Thank you for the comments, now get your points and agree with you.
> > > > I merged your patch together, also corrected the typo in the commit message.
> > > > Please help review the attached patch. Thank you !
> > >
> > > Sorry, there was a problem in my diff. Two tests fail when
> > > EMACS_PYTHON_INTERPRETER is not found. Please apply the attached
> > > diff. It also includes a suggestion for improving the error message.
> > > Please consider.
> >
> > Merged your changes and tested on my local (with python/python3), it
> > works perfectly. Thank you.
> >
> > And the patch file is attached .
>
> Thanks, it looks good to me.
Thanks, installed on master, and closing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 10:55:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This change caused python-tests failures on macOS. See attached log.
On this machine which has the standard macOS Python installation, 'python' is python 2, which apparently the tests don't cope very well with. (Have you verified that they do?)
The tests pass if modified to prefer Python 3:
@@ -3722,2 +3722,2 @@ python-tests-get-shell-interpreter
- (cl-some #'executable-find '("python" "python3" "python2"))))))
+ (cl-some #'executable-find '("python3" "python" "python2"))))))
[python-tests.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 12:08:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård wrote:
> This change caused python-tests failures on macOS. See attached log.
>
> On this machine which has the standard macOS Python installation, 'python' is python 2, which apparently the tests don't cope very well with. (Have you verified that they do?)
>
> The tests pass if modified to prefer Python 3:
>
> @@ -3722,2 +3722,2 @@ python-tests-get-shell-interpreter
> - (cl-some #'executable-find '("python" "python3" "python2"))))))
> + (cl-some #'executable-find '("python3" "python" "python2"))))))
All ERTs pass with Python 2 on Linux (Ubuntu 22.04). So it seems to
me that this is an issue with Python 2 on Mac. Maybe the workaround
using "tty.setraw(0)" is not working with Python 2 on Mac? Could you
test if the native completion is working with Python 2?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 12:23:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 70815 <at> debbugs.gnu.org (full text, mbox):
26 maj 2024 kl. 14.05 skrev kobarity <kobarity <at> gmail.com>:
> All ERTs pass with Python 2 on Linux (Ubuntu 22.04). So it seems to
> me that this is an issue with Python 2 on Mac. Maybe the workaround
> using "tty.setraw(0)" is not working with Python 2 on Mac? Could you
> test if the native completion is working with Python 2?
Not sure how to test that, but if I run python 2 interactively from a terminal then no completion appears to be active (although I'm not sure if something could make it work).
Given the status of Python 2 in general and on macOS in particular (there is a warning that it is only present for compatibility with legacy software) this is not very surprising. I don't think it's something we need to fix in Emacs.
Is there a reason not to apply the suggested patch to prefer `python3` to `python`?
Or put differently, why would `python-shell-interpreter` and `python-tests-get-shell-interpreter` use different preferences?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 12:38:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård wrote:
>
> 26 maj 2024 kl. 14.05 skrev kobarity <kobarity <at> gmail.com>:
>
> > All ERTs pass with Python 2 on Linux (Ubuntu 22.04). So it seems to
> > me that this is an issue with Python 2 on Mac. Maybe the workaround
> > using "tty.setraw(0)" is not working with Python 2 on Mac? Could you
> > test if the native completion is working with Python 2?
>
> Not sure how to test that, but if I run python 2 interactively from a terminal then no completion appears to be active (although I'm not sure if something could make it work).
Sorry, I forgot that native completion does not work on Mac, even with
Python 3. What I wanted to know is if there is unexpected echo backs
with Python 2 on Mac.
> Given the status of Python 2 in general and on macOS in particular (there is a warning that it is only present for compatibility with legacy software) this is not very surprising. I don't think it's something we need to fix in Emacs.
I agree.
> Is there a reason not to apply the suggested patch to prefer `python3` to `python`?
> Or put differently, why would `python-shell-interpreter` and `python-tests-get-shell-interpreter` use different preferences?
Maybe it is better to prefer "python3", but I don't know if that would
reliably prevent the problem. The best way would be to skip some
tests if the selected interpreter is Python 2 and it is running on
Mac.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 13:26:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 70815 <at> debbugs.gnu.org (full text, mbox):
26 maj 2024 kl. 14.36 skrev kobarity <kobarity <at> gmail.com>:
> Sorry, I forgot that native completion does not work on Mac, even with
> Python 3. What I wanted to know is if there is unexpected echo backs
> with Python 2 on Mac.
Not that I can see when running an interactive Python shell in Emacs, no.
> Maybe it is better to prefer "python3", but I don't know if that would
> reliably prevent the problem. The best way would be to skip some
> tests if the selected interpreter is Python 2 and it is running on
> Mac.
Why select Python 2 in the first place? Is it more important to test Python 2 than Python 3 on other platforms?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 14:18:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård wrote:
>
> 26 maj 2024 kl. 14.36 skrev kobarity <kobarity <at> gmail.com>:
>
> > Sorry, I forgot that native completion does not work on Mac, even with
> > Python 3. What I wanted to know is if there is unexpected echo backs
> > with Python 2 on Mac.
>
> Not that I can see when running an interactive Python shell in Emacs, no.
Could you see what is returned when you enter the following line in
Inferior Python buffer running Python 2 on Mac?
__PYTHON_EL_eval("print(\"Hello\")\n", "")
> > Maybe it is better to prefer "python3", but I don't know if that would
> > reliably prevent the problem. The best way would be to skip some
> > tests if the selected interpreter is Python 2 and it is running on
> > Mac.
>
> Why select Python 2 in the first place? Is it more important to test Python 2 than Python 3 on other platforms?
I am not saying that Python 2 (or simple "python") should be the
first. I do agree that "python3" should be preferred than "python".
My point is that we cannot assure that Python 2 is not selected. One
example is EMACS_PYTHON_INTERPRETER environment variable introduced by
the patch. It can specify the interpreter used in ERTs. So a Mac
user may set EMACS_PYTHON_INTERPRETER to "python".
I wrote in the previous mail:
> As for EMACS_PYTHON_INTERPRETER, I am a little doubtful that it is the
> right thing to introduce. It allows the ERT runner to specify the
> interpreter. It's OK for ERTs that can be run on both Python 2 and 3,
> but you may want to write an ERT that can only be run on Python 3.
At the time of writing, I assumed that current ERTs can be run on both
Python 2 and 3 on all platforms. However, it turned out that it was
wrong. Some tests fail with Python 2 on Mac. So I think we need some
mechanism to skip test based on the interpreter version and the
platform.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 15:02:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 70815 <at> debbugs.gnu.org (full text, mbox):
kobarity wrote:
>
> Mattias Engdegård wrote:
> >
> > 26 maj 2024 kl. 14.36 skrev kobarity <kobarity <at> gmail.com>:
> >
> > > Sorry, I forgot that native completion does not work on Mac, even with
> > > Python 3. What I wanted to know is if there is unexpected echo backs
> > > with Python 2 on Mac.
> >
> > Not that I can see when running an interactive Python shell in Emacs, no.
>
> Could you see what is returned when you enter the following line in
> Inferior Python buffer running Python 2 on Mac?
>
> __PYTHON_EL_eval("print(\"Hello\")\n", "")
Sorry, it was meaningless.
Please try evaluating the following expression in the Python buffer
after invoking Inferior Python buffer running Python 2.
(python-shell-send-string-no-output "print('a')")
Expected value is "a", but I suspect that this is not the case with
Python 2 on Mac.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 15:26:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 70815 <at> debbugs.gnu.org (full text, mbox):
26 maj 2024 kl. 17.00 skrev kobarity <kobarity <at> gmail.com>:
> Please try evaluating the following expression in the Python buffer
> after invoking Inferior Python buffer running Python 2.
>
> (python-shell-send-string-no-output "print('a')")
The result is "a".
> My point is that we cannot assure that Python 2 is not selected. One
> example is EMACS_PYTHON_INTERPRETER environment variable introduced by
> the patch. It can specify the interpreter used in ERTs. So a Mac
> user may set EMACS_PYTHON_INTERPRETER to "python".
Fair enough. I take no great interest in making the tests pass with such an environment variable assignment; at the very minimum, they should pass in the default configuration.
> So I think we need some
> mechanism to skip test based on the interpreter version and the
> platform.
Time permitting, I will be happy to run instrumented test runs if it would help you find out exactly why the test fail with Python 2.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 15:40:01 GMT)
Full text and
rfc822 format available.
Message #73 received at 70815 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Sun, 26 May 2024 12:52:54 +0200
> Cc: Lin Sun <sunlin7.mail <at> gmail.com>,
> stefankangas <at> gmail.com,
> 70815 <at> debbugs.gnu.org,
> Eli Zaretskii <eliz <at> gnu.org>
>
> This change caused python-tests failures on macOS. See attached log.
>
> On this machine which has the standard macOS Python installation, 'python' is python 2, which apparently the tests don't cope very well with. (Have you verified that they do?)
>
> The tests pass if modified to prefer Python 3:
>
> @@ -3722,2 +3722,2 @@ python-tests-get-shell-interpreter
> - (cl-some #'executable-find '("python" "python3" "python2"))))))
> + (cl-some #'executable-find '("python3" "python" "python2"))))))
I don't like this preference. It is basically wrong, because it
second-guesses what Python is _the_ Python on the user's machine.
Let's try to find another solution. If worse comes to worst, we could
make a change specific to macOS, but I hope we won't need to.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 15:54:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 70815 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Sun, 26 May 2024 15:23:46 +0200
> Cc: Lin Sun <sunlin7.mail <at> gmail.com>,
> stefankangas <at> gmail.com,
> 70815 <at> debbugs.gnu.org,
> Eli Zaretskii <eliz <at> gnu.org>
>
> Why select Python 2 in the first place? Is it more important to test Python 2 than Python 3 on other platforms?
Why do you have "python" as python2 when you have Python 3.x
installed? The usual practice is to have "python" invoke the
preferred version, which is normally the latest one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 15:58:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 70815 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 26 May 2024 23:15:50 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: Lin Sun <sunlin7.mail <at> gmail.com>,
> stefankangas <at> gmail.com,
> 70815 <at> debbugs.gnu.org,
> Eli Zaretskii <eliz <at> gnu.org>
>
> > Why select Python 2 in the first place? Is it more important to test Python 2 than Python 3 on other platforms?
>
> I am not saying that Python 2 (or simple "python") should be the
> first. I do agree that "python3" should be preferred than "python".
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?
> At the time of writing, I assumed that current ERTs can be run on both
> Python 2 and 3 on all platforms. However, it turned out that it was
> wrong. Some tests fail with Python 2 on Mac. So I think we need some
> mechanism to skip test based on the interpreter version and the
> platform.
If macOS needs special treatment, here, we can install a change
specific to macOS. But let's not skew all the platforms because of
macOS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 26 May 2024 23:08:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 70815 <at> debbugs.gnu.org (full text, mbox):
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.
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.
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 27 May 2024 10:26:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 70815 <at> debbugs.gnu.org (full text, mbox):
26 maj 2024 kl. 17.52 skrev Eli Zaretskii <eliz <at> gnu.org>:
> Why do you have "python" as python2 when you have Python 3.x
> installed? The usual practice is to have "python" invoke the
> preferred version, which is normally the latest one.
That is a misunderstanding. It is not at all unusual to have plain `python` being Python 2 for compatibility with old scripts. (A long-running debate point in the transition from Python 2 to 3.)
In any case, this set-up is standard in macOS (at least my version), and I'm quite sure I've seen similar arrangements in other systems.
What we are debating now is whether it is worth making the tests pass for certain Python 2 installations if the user somehow prefers those (with EMACS_PYTHON_INTERPRETER), and if so, how.
Kobarity and Lin Sun, wouldn't it make sense to tie the interpreter to test to `python-shell-interpreter`?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 27 May 2024 11:19:01 GMT)
Full text and
rfc822 format available.
Message #88 received at 70815 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 27 May 2024 11:21:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, May 27, 2024, 03:24 Mattias Engdegård <mattias.engdegard <at> gmail.com>
wrote:
> 26 maj 2024 kl. 17.52 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> > Why do you have "python" as python2 when you have Python 3.x
> > installed? The usual practice is to have "python" invoke the
> > preferred version, which is normally the latest one.
>
> That is a misunderstanding. It is not at all unusual to have plain
> `python` being Python 2 for compatibility with old scripts. (A long-running
> debate point in the transition from Python 2 to 3.)
>
> In any case, this set-up is standard in macOS (at least my version), and
> I'm quite sure I've seen similar arrangements in other systems.
>
> What we are debating now is whether it is worth making the tests pass for
> certain Python 2 installations if the user somehow prefers those (with
> EMACS_PYTHON_INTERPRETER), and if so, how.
>
> Kobarity and Lin Sun, wouldn't it make sense to tie the interpreter to
> test to `python-shell-interpreter`?
>
Hi Eli, it's not worth to make the cases for user perfers
EMACS_PYTHON_INTERPRETER.
It's failed naturally if the interpreter version is not supported anymore
or not supported yet.
For python2, as we discussed on original patch thread, it may be will still
exists for many years, so we need keep compatible with it, but we may skip
the cases that not working for python2 anymore.
And I'm trying to get the details of the failure.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 27 May 2024 12:22:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 70815 <at> debbugs.gnu.org (full text, mbox):
27 maj 2024 kl. 13.18 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> 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.
The `python` binary can very well be the one nobody wants to use, it's just that it has a long-term legacy lease on the file name. For example, on this system (with the unmodified system default Python installations):
|~% python
|
|WARNING: Python 2.7 is not recommended.
|This version is included in macOS for compatibility with legacy software.
|Future versions of macOS will not include Python 2.7.
|Instead, it is recommended that you transition to using 'python3' from within Terminal.
I very much agree that we should make our own decision about what platforms and versions to support but in this case it's just a matter of what we want to use for testing our own code, and given more than one Python, the one named `python3` is more likely to be relevant than just `python`.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 27 May 2024 12:35:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård wrote:
> > Please try evaluating the following expression in the Python buffer
> > after invoking Inferior Python buffer running Python 2.
> >
> > (python-shell-send-string-no-output "print('a')")
>
> The result is "a".
Thanks. Then I have no idea why it fails. It's difficult for me to
further investigate as I don't have Mac environment.
Mattias Engdegård wrote:
> Kobarity and Lin Sun, wouldn't it make sense to tie the interpreter to test to `python-shell-interpreter`?
I don't think it is a good idea. `python-shell-interpreter' can be a
variety of things. It may be IPython, PyPy, or even Poetry.
`python-tests-shell-interpreter' exists to override
`python-shell-interpreter'.
Lin Sun wrote:
> Hi Eli, it's not worth to make the cases for user perfers EMACS_PYTHON_INTERPRETER.
> It's failed naturally if the interpreter version is not supported anymore or not supported yet.
I think we are still supporting Python 2 on Mac. It is just that
there seems to be problems with some features.
ERTs exist to find bugs. In that sense, I think the ERTs have worked
well. We probably have found the bug with Python 2 on Mac, unless
there is a bug on the ERTs. So the natural and best course is to fix
that bug. Changing the order of the interpreters to find or skipping
some ERTs does not solve the problem. However, it seems that only a
limited number of people can pursue the problem on Mac, and fewer
people will have trouble with Python 2 issues. So for now, I think it
is better to skip these ERTs for Python 2 on Mac only.
The problem is that there is no convenient way to skip some ERTs based
on the interpreter's version. I will think about it, but it will be
over the weekend at the earliest.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 27 May 2024 12:45:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 70815 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Mon, 27 May 2024 14:20:21 +0200
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,
> kobarity <at> gmail.com,
> sunlin7.mail <at> gmail.com,
> 70815 <at> debbugs.gnu.org
>
> I very much agree that we should make our own decision about what platforms and versions to support but in this case it's just a matter of what we want to use for testing our own code, and given more than one Python, the one named `python3` is more likely to be relevant than just `python`.
If the Python experts agree, I won't object.
FTR, I have Python 3.x installed here, but no "python3", only
"python".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 27 May 2024 12:47:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 70815 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 27 May 2024 21:33:03 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> Stefan Kangas <stefankangas <at> gmail.com>,
> 70815 <at> debbugs.gnu.org
>
> ERTs exist to find bugs. In that sense, I think the ERTs have worked
> well. We probably have found the bug with Python 2 on Mac, unless
> there is a bug on the ERTs. So the natural and best course is to fix
> that bug. Changing the order of the interpreters to find or skipping
> some ERTs does not solve the problem. However, it seems that only a
> limited number of people can pursue the problem on Mac, and fewer
> people will have trouble with Python 2 issues. So for now, I think it
> is better to skip these ERTs for Python 2 on Mac only.
I'm okay with that solution as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Tue, 28 May 2024 12:33:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 70815 <at> debbugs.gnu.org (full text, mbox):
27 maj 2024 kl. 14.33 skrev kobarity <kobarity <at> gmail.com>:
> We probably have found the bug with Python 2 on Mac, unless
> there is a bug on the ERTs.
It could just be a mismatch of expectations. With python-shell-interpreter set to "python2", tab-completion in the Python interactive shell works but in a diminished capacity. For example, 'pri<TAB>' completes to 'print' but 'math.sq<TAB>' does not complete to 'math.sqrt(' as it does in Python 3.
> Changing the order of the interpreters to find or skipping
> some ERTs does not solve the problem.
But it does fix a different problem: it tests python-mode with Python 3, which is more important.
> However, it seems that only a
> limited number of people can pursue the problem on Mac, and fewer
> people will have trouble with Python 2 issues. So for now, I think it
> is better to skip these ERTs for Python 2 on Mac only.
We can probably agree that absent explicit information about what version the user wants tested, we should test python-mode with Python 3 on macOS and other platforms.
If you think it is important we can also test it with Python 2 if available. Rejigging the tests to run for multiple Python versions is certainly possible but would be some work.
Meanwhile I'm just going to make the tests use the same logic as python.el for selecting the binary to use, as there does not seem to be a reason why this would make anything worse.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Tue, 28 May 2024 15:19:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård wrote:
>
> 27 maj 2024 kl. 14.33 skrev kobarity <kobarity <at> gmail.com>:
>
> > We probably have found the bug with Python 2 on Mac, unless
> > there is a bug on the ERTs.
>
> It could just be a mismatch of expectations. With python-shell-interpreter set to "python2", tab-completion in the Python interactive shell works but in a diminished capacity. For example, 'pri<TAB>' completes to 'print' but 'math.sq<TAB>' does not complete to 'math.sqrt(' as it does in Python 3.
I think it is a "bug". Because it is working with Python 2 on Linux
(with native and non-native completions), and I believe many would
expect it to work.
In any case, to accommodate the ERTs for such differences, a mechanism
to skip an ERT based on the interpreter version (or some other
property) is needed.
> > Changing the order of the interpreters to find or skipping
> > some ERTs does not solve the problem.
>
> But it does fix a different problem: it tests python-mode with Python 3, which is more important.
As I mentioned before, I am not opposed to prioritize "python3". I
don't think anyone is arguing that "python" should precede "python3"
anymore.
> > However, it seems that only a
> > limited number of people can pursue the problem on Mac, and fewer
> > people will have trouble with Python 2 issues. So for now, I think it
> > is better to skip these ERTs for Python 2 on Mac only.
>
> We can probably agree that absent explicit information about what version the user wants tested, we should test python-mode with Python 3 on macOS and other platforms.
>
> If you think it is important we can also test it with Python 2 if available. Rejigging the tests to run for multiple Python versions is certainly possible but would be some work.
>
> Meanwhile I'm just going to make the tests use the same logic as python.el for selecting the binary to use, as there does not seem to be a reason why this would make anything worse.
>
You have an option to set EMACS_PYTHON_INTERPRETER environment
variable to "python3", just for now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Tue, 28 May 2024 16:12:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 70815 <at> debbugs.gnu.org (full text, mbox):
28 maj 2024 kl. 17.17 skrev kobarity <kobarity <at> gmail.com>:
> I think it is a "bug". Because it is working with Python 2 on Linux
> (with native and non-native completions), and I believe many would
> expect it to work.
Could be, but it's hard to believe that whatever completion defect we have in python.el for Python 2 on macOS is affecting a lot of people. It seems usable enough to me, given the circumstances.
> As I mentioned before, I am not opposed to prioritize "python3". I
> don't think anyone is arguing that "python" should precede "python3"
> anymore.
Thank you. I don't want to steamroller a change, but there is a real risk of paralysis from too much deference to code details that might just as well have been a simple oversight, which I believe is what happened here.
And again, I'd be happy to help debug the problem on macOS if someone is very bothered about the problem now or in the future.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Wed, 29 May 2024 14:59:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård wrote:
> 28 maj 2024 kl. 17.17 skrev kobarity <kobarity <at> gmail.com>:
>
> > I think it is a "bug". Because it is working with Python 2 on Linux
> > (with native and non-native completions), and I believe many would
> > expect it to work.
>
> Could be, but it's hard to believe that whatever completion defect we have in python.el for Python 2 on macOS is affecting a lot of people. It seems usable enough to me, given the circumstances.
>
> > As I mentioned before, I am not opposed to prioritize "python3". I
> > don't think anyone is arguing that "python" should precede "python3"
> > anymore.
>
> Thank you. I don't want to steamroller a change, but there is a real risk of paralysis from too much deference to code details that might just as well have been a simple oversight, which I believe is what happened here.
I'm not sure what you are proposing. What I want to do now is not to
fix the "bug", but to accept the current situation and express it as
the ERTs. Otherwise, even if we change the order of the interpreters,
it will fail when some Mac user sets EMACS_PYTHON_INTERPRETER to
"python" and runs ERTs for example.
Even if we could fix this "bug" right away, or even if we made the
decision to stop Python 2 support on Mac, I believe we would still
need a mechanism to skip an ERT based on the interpreter version
because similar stories would still come up.
Unless you are opposed to adding such a mechanism to ERT, I don't see
much difference of opinion between us. If you want to change the
order of the interpreters as soon as possible, I am not opposed to
that either.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Thu, 30 May 2024 10:11:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 70815 <at> debbugs.gnu.org (full text, mbox):
29 maj 2024 kl. 16.56 skrev kobarity <kobarity <at> gmail.com>:
> What I want to do now is not to
> fix the "bug", but to accept the current situation and express it as
> the ERTs. Otherwise, even if we change the order of the interpreters,
> it will fail when some Mac user sets EMACS_PYTHON_INTERPRETER to
> "python" and runs ERTs for example.
That's very generous of you but watch out so that you don't waste time on busywork that isn't strictly necessary.
I did adjust the order of the interpreters in 9c7de10079, by the way; that took care of my own itches for this bug.
Do whatever you feel is necessary but again, your own time is precious.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 02 Jun 2024 13:23:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mattias Engdegård wrote:
> 29 maj 2024 kl. 16.56 skrev kobarity <kobarity <at> gmail.com>:
>
> > What I want to do now is not to
> > fix the "bug", but to accept the current situation and express it as
> > the ERTs. Otherwise, even if we change the order of the interpreters,
> > it will fail when some Mac user sets EMACS_PYTHON_INTERPRETER to
> > "python" and runs ERTs for example.
>
> That's very generous of you but watch out so that you don't waste time on busywork that isn't strictly necessary.
>
> I did adjust the order of the interpreters in 9c7de10079, by the way; that took care of my own itches for this bug.
>
> Do whatever you feel is necessary but again, your own time is precious.
Thanks, but as I mentioned before, this is something I thought we
would need sooner or later, even before the bug was found.
The attached patch is my proposal. I added PRED argument to
`python-tests-get-shell-interpreter' to allow conditions to be
specified when selecting an interpreter. For now, I only provide a
predicate that the major version of the interpreter is 3, but I think
it would be easy to add.
It would be helpful if you could try each of the following on Mac.
1. Set EMACS_PYTHON_INTERPRETER environment variable to "python" and
run ERTs. The expectation is that the 7 ERTs that previously
resulted in errors will be skipped.
2. Revert 9c7de10079 and run ERTs. The expectation is that the 7 ERTs
that previously failed will succeed.
BTW, Apple seems to have removed Python 2 in 2022 MacOS 12.3. Is your
Python 2 installed with brew or something else? Or is it an old Apple
one?
[0001-Specify-Python-3-in-some-ERTs-on-Mac.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 03 Jun 2024 14:04:01 GMT)
Full text and
rfc822 format available.
Message #124 received at 70815 <at> debbugs.gnu.org (full text, mbox):
2 juni 2024 kl. 15.20 skrev kobarity <kobarity <at> gmail.com>:
> The attached patch is my proposal. I added PRED argument to
> `python-tests-get-shell-interpreter' to allow conditions to be
> specified when selecting an interpreter. For now, I only provide a
> predicate that the major version of the interpreter is 3, but I think
> it would be easy to add.
That would work for me. (It could maybe be simplified a bit but that's not very important.)
> 1. Set EMACS_PYTHON_INTERPRETER environment variable to "python" and
> run ERTs. The expectation is that the 7 ERTs that previously
> resulted in errors will be skipped.
With EMACS_PYTHON_INTERPRETER=python3 or unset
SKIPPED python-shell-completion-at-point-ipython
SKIPPED python-shell-completion-at-point-jedi-completer
With EMACS_PYTHON_INTERPRETER=python
SKIPPED python-completion-at-point-1
SKIPPED python-completion-at-point-2
SKIPPED python-completion-at-point-native-1
SKIPPED python-completion-at-point-native-2
SKIPPED python-completion-at-point-native-with-eldoc-1
SKIPPED python-completion-at-point-native-with-ffap-1
SKIPPED python-shell-completion-at-point-1
SKIPPED python-shell-completion-at-point-ipython
SKIPPED python-shell-completion-at-point-jedi-completer
> 2. Revert 9c7de10079 and run ERTs. The expectation is that the 7 ERTs
> that previously failed will succeed.
No, they still fail:
7 unexpected results:
FAILED python-completion-at-point-1
FAILED python-completion-at-point-2
FAILED python-completion-at-point-native-1
FAILED python-completion-at-point-native-2
FAILED python-completion-at-point-native-with-eldoc-1
FAILED python-completion-at-point-native-with-ffap-1
FAILED python-shell-completion-at-point-1
2 skipped results:
SKIPPED python-shell-completion-at-point-ipython
SKIPPED python-shell-completion-at-point-jedi-completer
> Apple seems to have removed Python 2 in 2022 MacOS 12.3. Is your
> Python 2 installed with brew or something else? Or is it an old Apple
> one?
It's the standard setup of an older version of macOS (the hardware of that machine can't run 12.3).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 03 Jun 2024 14:36:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård wrote:
> 2 juni 2024 kl. 15.20 skrev kobarity <kobarity <at> gmail.com>:
> > 1. Set EMACS_PYTHON_INTERPRETER environment variable to "python" and
> > run ERTs. The expectation is that the 7 ERTs that previously
> > resulted in errors will be skipped.
>
> With EMACS_PYTHON_INTERPRETER=python3 or unset
>
> SKIPPED python-shell-completion-at-point-ipython
> SKIPPED python-shell-completion-at-point-jedi-completer
>
> With EMACS_PYTHON_INTERPRETER=python
>
> SKIPPED python-completion-at-point-1
> SKIPPED python-completion-at-point-2
> SKIPPED python-completion-at-point-native-1
> SKIPPED python-completion-at-point-native-2
> SKIPPED python-completion-at-point-native-with-eldoc-1
> SKIPPED python-completion-at-point-native-with-ffap-1
> SKIPPED python-shell-completion-at-point-1
> SKIPPED python-shell-completion-at-point-ipython
> SKIPPED python-shell-completion-at-point-jedi-completer
Thanks, this is as expected.
> > 2. Revert 9c7de10079 and run ERTs. The expectation is that the 7 ERTs
> > that previously failed will succeed.
>
> No, they still fail:
>
> 7 unexpected results:
> FAILED python-completion-at-point-1
> FAILED python-completion-at-point-2
> FAILED python-completion-at-point-native-1
> FAILED python-completion-at-point-native-2
> FAILED python-completion-at-point-native-with-eldoc-1
> FAILED python-completion-at-point-native-with-ffap-1
> FAILED python-shell-completion-at-point-1
>
> 2 skipped results:
> SKIPPED python-shell-completion-at-point-ipython
> SKIPPED python-shell-completion-at-point-jedi-completer
Maybe I did not make the right request. What I wanted you to try was
to make the following changes after applying my patch in the previous
email.
diff --git a/test/lisp/progmodes/python-tests.el b/test/lisp/progmodes/python-tests.el
index 970ec32bc0c..77b30f8bdbc 100644
--- a/test/lisp/progmodes/python-tests.el
+++ b/test/lisp/progmodes/python-tests.el
@@ -3770,7 +3770,7 @@ python-tests-get-shell-interpreter
;; Use the same order as for the default value of
;; `python-shell-interpreter'.
(delq nil (mapcar #'python-tests--get-interpreter-info
- '("python3" "python" "python2"))))))
+ '("python" "python3" "python2"))))))
(cl-some (or pred #'car) python-tests-shell-interpreters))
(defun python-tests--get-interpreter-info (name)
If you have tried it this way, could you tell me what the value of
`python-tests-shell-interpreters' is?
> > Apple seems to have removed Python 2 in 2022 MacOS 12.3. Is your
> > Python 2 installed with brew or something else? Or is it an old Apple
> > one?
>
> It's the standard setup of an older version of macOS (the hardware of that machine can't run 12.3).
I understood.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 03 Jun 2024 16:41:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 70815 <at> debbugs.gnu.org (full text, mbox):
kobarity wrote:
> Mattias Engdegård wrote:
> > > 2. Revert 9c7de10079 and run ERTs. The expectation is that the 7 ERTs
> > > that previously failed will succeed.
> >
> > No, they still fail:
> >
> > 7 unexpected results:
> > FAILED python-completion-at-point-1
> > FAILED python-completion-at-point-2
> > FAILED python-completion-at-point-native-1
> > FAILED python-completion-at-point-native-2
> > FAILED python-completion-at-point-native-with-eldoc-1
> > FAILED python-completion-at-point-native-with-ffap-1
> > FAILED python-shell-completion-at-point-1
> >
> > 2 skipped results:
> > SKIPPED python-shell-completion-at-point-ipython
> > SKIPPED python-shell-completion-at-point-jedi-completer
>
> Maybe I did not make the right request. What I wanted you to try was
> to make the following changes after applying my patch in the previous
> email.
>
> diff --git a/test/lisp/progmodes/python-tests.el b/test/lisp/progmodes/python-tests.el
> index 970ec32bc0c..77b30f8bdbc 100644
> --- a/test/lisp/progmodes/python-tests.el
> +++ b/test/lisp/progmodes/python-tests.el
> @@ -3770,7 +3770,7 @@ python-tests-get-shell-interpreter
> ;; Use the same order as for the default value of
> ;; `python-shell-interpreter'.
> (delq nil (mapcar #'python-tests--get-interpreter-info
> - '("python3" "python" "python2"))))))
> + '("python" "python3" "python2"))))))
> (cl-some (or pred #'car) python-tests-shell-interpreters))
>
> (defun python-tests--get-interpreter-info (name)
>
> If you have tried it this way, could you tell me what the value of
> `python-tests-shell-interpreters' is?
Sorry, I realized my mistake. I will revise my patch within a few
days.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Tue, 04 Jun 2024 14:32:01 GMT)
Full text and
rfc822 format available.
Message #133 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
kobarity wrote:
>
> kobarity wrote:
> > Mattias Engdegård wrote:
> > > > 2. Revert 9c7de10079 and run ERTs. The expectation is that the 7 ERTs
> > > > that previously failed will succeed.
> > >
> > > No, they still fail:
> > >
> > > 7 unexpected results:
> > > FAILED python-completion-at-point-1
> > > FAILED python-completion-at-point-2
> > > FAILED python-completion-at-point-native-1
> > > FAILED python-completion-at-point-native-2
> > > FAILED python-completion-at-point-native-with-eldoc-1
> > > FAILED python-completion-at-point-native-with-ffap-1
> > > FAILED python-shell-completion-at-point-1
> > >
> > > 2 skipped results:
> > > SKIPPED python-shell-completion-at-point-ipython
> > > SKIPPED python-shell-completion-at-point-jedi-completer
> >
> > Maybe I did not make the right request. What I wanted you to try was
> > to make the following changes after applying my patch in the previous
> > email.
> >
> > diff --git a/test/lisp/progmodes/python-tests.el b/test/lisp/progmodes/python-tests.el
> > index 970ec32bc0c..77b30f8bdbc 100644
> > --- a/test/lisp/progmodes/python-tests.el
> > +++ b/test/lisp/progmodes/python-tests.el
> > @@ -3770,7 +3770,7 @@ python-tests-get-shell-interpreter
> > ;; Use the same order as for the default value of
> > ;; `python-shell-interpreter'.
> > (delq nil (mapcar #'python-tests--get-interpreter-info
> > - '("python3" "python" "python2"))))))
> > + '("python" "python3" "python2"))))))
> > (cl-some (or pred #'car) python-tests-shell-interpreters))
> >
> > (defun python-tests--get-interpreter-info (name)
> >
> > If you have tried it this way, could you tell me what the value of
> > `python-tests-shell-interpreters' is?
>
> Sorry, I realized my mistake. I will revise my patch within a few
> days.
The attached is the revised patch. In order to bind
`python-shell-interpreter' consistently, new macros
`python-tests-with-shell-interpreter' and
`python-tests-with-temp-buffer-with-shell-interpreter' were
introduced. The patch is larger because some of the indentations have
been changed by using new macros. I have fixed
`python-shell-interpreter' was not bound correctly in some ERTs, so
you might find new ERTs that fail with Python 2 on Mac.
Same as before, it would be helpful if you could try each of the
following on Mac.
1. Set EMACS_PYTHON_INTERPRETER environment variable to "python" and
run ERTs. The expectation is that the 7 ERTs that previously
resulted in errors will be skipped.
2. Change the order of the interpreters in
`python-tests-get-shell-interpreter' to "python" "python3"
"python2" and run ERTs. The expectation is that the 7 ERTs that
previously failed will succeed.
Another change is the behavior when the interpreter specified in
EMACS_PYTHON_INTERPRETER is not found. In the current master, ERTs
are skipped if the interpreter specified by EMACS_PYTHON_INTERPRETER
is not found. This is because although
`python-tests-get-shell-interpreter' raises an error, `skip-unless'
ignores it.
However, if the interpreter specified by EMACS_PYTHON_INTERPRETER is
not found, it is likely that EMACS_PYTHON_INTERPRETER is incorrectly
configured, and I would prefer to let it fail rather than let it be
skipped. If it is better to be skipped, it would be better to have
`python-tests-get-shell-interpreter' return nil without raising an
error. I would like to hear Lin's and others opinions on this matter.
[0001-Specify-Python-3-in-some-ERTs-on-Mac.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Wed, 05 Jun 2024 10:28:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 70815 <at> debbugs.gnu.org (full text, mbox):
4 juni 2024 kl. 16.29 skrev kobarity <kobarity <at> gmail.com>:
> The attached is the revised patch. In order to bind
> `python-shell-interpreter' consistently, new macros
> `python-tests-with-shell-interpreter' and
> `python-tests-with-temp-buffer-with-shell-interpreter' were
> introduced. The patch is larger because some of the indentations have
> been changed by using new macros. I have fixed
> `python-shell-interpreter' was not bound correctly in some ERTs, so
> you might find new ERTs that fail with Python 2 on Mac.
It works here.
> 1. Set EMACS_PYTHON_INTERPRETER environment variable to "python" and
> run ERTs. The expectation is that the 7 ERTs that previously
> resulted in errors will be skipped.
Yes.
> 2. Change the order of the interpreters in
> `python-tests-get-shell-interpreter' to "python" "python3"
> "python2" and run ERTs. The expectation is that the 7 ERTs that
> previously failed will succeed.
Yes.
> However, if the interpreter specified by EMACS_PYTHON_INTERPRETER is
> not found, it is likely that EMACS_PYTHON_INTERPRETER is incorrectly
> configured, and I would prefer to let it fail rather than let it be
> skipped.
Yes, which is what happens with your patch, and I agree that this is the best outcome.
Would you like me to push your patch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Wed, 05 Jun 2024 11:55:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 70815 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård wrote:
>
> 4 juni 2024 kl. 16.29 skrev kobarity <kobarity <at> gmail.com>:
>
> > The attached is the revised patch. In order to bind
> > `python-shell-interpreter' consistently, new macros
> > `python-tests-with-shell-interpreter' and
> > `python-tests-with-temp-buffer-with-shell-interpreter' were
> > introduced. The patch is larger because some of the indentations have
> > been changed by using new macros. I have fixed
> > `python-shell-interpreter' was not bound correctly in some ERTs, so
> > you might find new ERTs that fail with Python 2 on Mac.
>
> It works here.
>
> > 1. Set EMACS_PYTHON_INTERPRETER environment variable to "python" and
> > run ERTs. The expectation is that the 7 ERTs that previously
> > resulted in errors will be skipped.
>
> Yes.
>
> > 2. Change the order of the interpreters in
> > `python-tests-get-shell-interpreter' to "python" "python3"
> > "python2" and run ERTs. The expectation is that the 7 ERTs that
> > previously failed will succeed.
>
> Yes.
>
> > However, if the interpreter specified by EMACS_PYTHON_INTERPRETER is
> > not found, it is likely that EMACS_PYTHON_INTERPRETER is incorrectly
> > configured, and I would prefer to let it fail rather than let it be
> > skipped.
>
> Yes, which is what happens with your patch, and I agree that this is the best outcome.
Thanks for the early confirmation.
> Would you like me to push your patch?
Thanks again. I will wait a few days to see if I can get feedback
from others.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sat, 08 Jun 2024 15:36:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 70815 <at> debbugs.gnu.org (full text, mbox):
kobarity wrote:
>
> Mattias Engdegård wrote:
> >
> > 4 juni 2024 kl. 16.29 skrev kobarity <kobarity <at> gmail.com>:
> >
> > > The attached is the revised patch. In order to bind
> > > `python-shell-interpreter' consistently, new macros
> > > `python-tests-with-shell-interpreter' and
> > > `python-tests-with-temp-buffer-with-shell-interpreter' were
> > > introduced. The patch is larger because some of the indentations have
> > > been changed by using new macros. I have fixed
> > > `python-shell-interpreter' was not bound correctly in some ERTs, so
> > > you might find new ERTs that fail with Python 2 on Mac.
> >
> > It works here.
> >
> > > 1. Set EMACS_PYTHON_INTERPRETER environment variable to "python" and
> > > run ERTs. The expectation is that the 7 ERTs that previously
> > > resulted in errors will be skipped.
> >
> > Yes.
> >
> > > 2. Change the order of the interpreters in
> > > `python-tests-get-shell-interpreter' to "python" "python3"
> > > "python2" and run ERTs. The expectation is that the 7 ERTs that
> > > previously failed will succeed.
> >
> > Yes.
> >
> > > However, if the interpreter specified by EMACS_PYTHON_INTERPRETER is
> > > not found, it is likely that EMACS_PYTHON_INTERPRETER is incorrectly
> > > configured, and I would prefer to let it fail rather than let it be
> > > skipped.
> >
> > Yes, which is what happens with your patch, and I agree that this is the best outcome.
>
> Thanks for the early confirmation.
>
> > Would you like me to push your patch?
>
> Thanks again. I will wait a few days to see if I can get feedback
> from others.
Since there doesn't seem to be any other feedback, could you please
apply the patch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Sun, 09 Jun 2024 14:09:01 GMT)
Full text and
rfc822 format available.
Message #145 received at 70815 <at> debbugs.gnu.org (full text, mbox):
8 juni 2024 kl. 17.34 skrev kobarity <kobarity <at> gmail.com>:
> Since there doesn't seem to be any other feedback, could you please
> apply the patch?
Certainly, now pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 10 Jun 2024 15:26:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 70815 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mattias Engdegård wrote:
>
> 8 juni 2024 kl. 17.34 skrev kobarity <kobarity <at> gmail.com>:
>
> > Since there doesn't seem to be any other feedback, could you please
> > apply the patch?
>
> Certainly, now pushed to master.
Thanks. I overlooked one thing. Could you also apply the attached
patch?
[0001-Fix-recent-change-to-python-tests.el.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70815; Package
emacs.
(Mon, 10 Jun 2024 15:56:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 70815 <at> debbugs.gnu.org (full text, mbox):
10 juni 2024 kl. 16.57 skrev kobarity <kobarity <at> gmail.com>:
> Thanks. I overlooked one thing. Could you also apply the attached
> patch?
Of course, pushed.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 09 Jul 2024 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 39 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.