GNU bug report logs -
#33979
26.1; python.el is not fully PEP 8 compliant for closing parens
Previous Next
To reply to this bug, email your comments to 33979 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33979
; Package
emacs
.
(Fri, 04 Jan 2019 20:49:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Barry Warsaw <barry <at> python.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 04 Jan 2019 20:49: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)]
I am spending some time playing with the default python.el to see where
it differs from the externally maintained python-mode.el. AFAICT,
python.el does not fully support PEP 8 (the document, not the tool) for
the indentation of closing parentheses.
Given this code, typed contemporaneously:
NUMBERS = [
(1, 2),
(3, 4),
(5, 6),
^----point
Now I hit RET and ]
NUMBERS = [
(1, 2),
(3, 4),
(5, 6),
]
^----point
However, if I hit TAB at point, the closing bracket gets moved to column
0:
NUMBERS = [
(1, 2),
(3, 4),
(5, 6),
]
While this style is PEP 8 compliant, so is this:
NUMBERS = [
(1, 2),
(3, 4),
(5, 6),
]
i.e. with the closing brace lined up under the beginning of the last
line. Quoting PEP 8:
> The closing brace/bracket/parenthesis on multiline constructs may
> either line up under the first non-whitespace character of the last
> line of list, as in: [EXAMPLES THAT LOOK LIKE WHAT I WANT]
> ...
> or it may be lined up under the first character of the line that
> starts the multiline construct, as in: [EXAMPLES THAT LOOK LIKE
> PYTHON.EL]
I've looked at python-indent--calculate-indentation in python.el and
AFAICT, there's no way to customize this behavior. Thus, python.el
violates PEP 8.
In GNU Emacs 26.1 (build 1, x86_64-apple-darwin17.5.0, NS appkit-1561.40 Version 10.13.4 (Build 17E202))
of 2018-05-30 built on resist.local
Windowing system distributor 'Apple', version 10.3.1671
Recent messages:
Checking 24 files in /usr/local/Cellar/emacs/26.1_1/share/emacs/26.1/lisp/cedet...
Checking 57 files in /usr/local/Cellar/emacs/26.1_1/share/emacs/26.1/lisp/calendar...
Checking 87 files in /usr/local/Cellar/emacs/26.1_1/share/emacs/26.1/lisp/calc...
Checking 105 files in /usr/local/Cellar/emacs/26.1_1/share/emacs/26.1/lisp/obsolete...
Checking for load-path shadows...done
You can run the command ‘report-emacs-bug’ with M-x r-em RET
Checking for load-path shadows...done
previous-line: Beginning of buffer [8 times]
Quit [6 times]
report-emacs-bug-insert-to-mailer: Subject, To or body not found
Quit [2 times]
Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs/26.1_1/share/info/emacs
--prefix=/usr/local/Cellar/emacs/26.1_1 --with-gnutls --without-x
--with-xml2 --without-dbus --without-imagemagick --with-ns
--disable-ns-self-contained'
Configured features:
JPEG NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS THREADS
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Py
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33979
; Package
emacs
.
(Tue, 05 Feb 2019 18:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 33979 <at> debbugs.gnu.org (full text, mbox):
> I've looked at python-indent--calculate-indentation in python.el and
> AFAICT, there's no way to customize this behavior. Thus, python.el
> violates PEP 8.
Just trying to understand this. The Python code one will type with
python.el will still be PEP8 compliant (correct me if I'm wrong). But
the python.el does violate PEP8 because it does not provide way to
customize this indentation behavior for closing brackets, right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33979
; Package
emacs
.
(Tue, 05 Feb 2019 22:32:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 33979 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Feb 5, 2019, at 10:53, Bhavin Gandhi <bhavin7392 <at> gmail.com> wrote:
>
>> I've looked at python-indent--calculate-indentation in python.el and
>> AFAICT, there's no way to customize this behavior. Thus, python.el
>> violates PEP 8.
>
> Just trying to understand this. The Python code one will type with python.el will still be PEP8 compliant (correct me if I'm wrong). But the python.el does violate PEP8 because it does not provide way to customize this indentation behavior for closing brackets, right?
Correct! Thanks for your consideration.
[signature.asc (application/pgp-signature, attachment)]
Added tag(s) confirmed.
Request was from
Bhavin Gandhi <bhavin7392 <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 06 Feb 2019 05:05:02 GMT)
Full text and
rfc822 format available.
Severity set to 'wishlist' from 'minor'
Request was from
Bhavin Gandhi <bhavin7392 <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 06 Feb 2019 05:05:02 GMT)
Full text and
rfc822 format available.
Forcibly Merged 20560 33979.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sat, 20 Apr 2019 20:59:02 GMT)
Full text and
rfc822 format available.
Removed tag(s) patch.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sat, 20 Apr 2019 21:08:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
20560 <at> debbugs.gnu.org and Fabrice Salvaire <fabrice.salvaire <at> orange.fr>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 17 Sep 2020 19:00:03 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 18 Sep 2020 11:12:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 272 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.