W391 blank line at end of file как исправить

ЕПрофи (515)

2 года назад

Вот спасибо! У меня оказался целый набор пустых строк)

W391 says that there should be one (and only one) blank line at the end of file. However, flake8 reports the error when there is at least one newline at the end of the file:

$ cat /tmp/test.py
def hello():
    print('hello')


hello()

$ hexdump -C /tmp/test.py
00000000  64 65 66 20 68 65 6c 6c  6f 28 29 3a 0a 20 20 20  |def hello():.   |
00000010  20 70 72 69 6e 74 28 27  68 65 6c 6c 6f 27 29 0a  | print('hello').|
00000020  0a 0a 68 65 6c 6c 6f 28  29 0a 0a                 |..hello()..|
0000002b

You can see above there is in fact one and only one blank line at the end of the file (0a is n). However, when I run flake8, I get the W391 error:

$ flake8 /tmp/test.py
/tmp/test.py:6:1: W391 blank line at end of file

Why is that?

asked Nov 10, 2019 at 2:59

Apparently vim automatically adds a newline to every file, which fools me into thinking that last blank line isn’t there. Over time this implicit newline confused me into thinking two newline characters at the end created one blank line.

So, the warning is correct. There should be one and only one n at the end of the file.

answered Nov 10, 2019 at 19:12

A newline at the end of a file does not mean that there needs to be an empty line. Your editor may not show this to you but the raw bytes would look like:

# your python code
def foo():n
    return barn

If you don’t have the last n there then you will see W391. You seem to be doing

Edited to fix the last example.

@davidaames —

Could you provide some sample code where this is an issue? Thanks.

Hey, I seem to be having this issue as well, with this sample code:

        raise Exception('Error: Incorrect new dag flows on line '
                        + str(i))

Since this error is highly whitespace-sensitive, I don’t think it can be reproduced with simple code blocks as those are stripped. Please upload files.

That said, I suspect that the initial problem was that the end of the file looked as follows:

# your python code
def foo():n
    return barn
    n

Note that the last line here is not empty but has 4 spaces. This should raise W391. It was then attempted to fix the error by removing the last newline, but that left the four spaces in the now last line, which caused W292 to be raised.

As a workaround in the meantime, I have a bit in my editor(vim) config(.vimrc) that strips trailing whitespace whenever a buffer is saved. That might help you (@justinkterry) in the short term, if you use vim and are ok with your editor cleaning whitespace up for you:

function! TrimTrailingWhitespace()
  :%s/s+$//e
endfunction
autocmd BufWritePre *.py :call TrimTrailingWhitespace()

or more concisely:

autocmd BufWritePre *.py :%s/s+$//e  " Trim trailing whitespace

W391 appears to supercede W292.

$ echo -n "a = 1" > file.py | pycodestyle file.py
file.py:1:1: W391 blank line at end of file

Seems like W292 should be raised first.

Hmmm, for what it’s worth, it seems like Vim inserts the newline at the end of the file, but it doesn’t look like there is a newline. I wonder if this is what was happening with the OP?

It took me quite a while to believe that I actually deserved to get W391, but when I hexdump -C /the/file | tail, it was true! The last two bytes were 0a 0a.

This is the file I use:

# -*- coding: utf-8 -*-
"""Function to sanitise paths."""

from pathvalidate import sanitize_filename
import os


def sanitise(*paths):
    return os.path.join(*[sanitize_filename(x) for x in paths])

The last line does have a [W292] warning on it. Flake8 passes fine.

Running hexdump, get:

hexdump -C sanitise.py | tail
00000040  70 61 74 68 76 61 6c 69  64 61 74 65 20 69 6d 70  |pathvalidate imp|
00000050  6f 72 74 20 73 61 6e 69  74 69 7a 65 5f 66 69 6c  |ort sanitize_fil|
00000060  65 6e 61 6d 65 0a 69 6d  70 6f 72 74 20 6f 73 0a  |ename.import os.|
00000070  0a 0a 64 65 66 20 73 61  6e 69 74 69 73 65 28 2a  |..def sanitise(*|
00000080  70 61 74 68 73 29 3a 0a  20 20 20 20 72 65 74 75  |paths):.    retu|
00000090  72 6e 20 6f 73 2e 70 61  74 68 2e 6a 6f 69 6e 28  |rn os.path.join(|
000000a0  2a 5b 73 61 6e 69 74 69  7a 65 5f 66 69 6c 65 6e  |*[sanitize_filen|
000000b0  61 6d 65 28 78 29 20 66  6f 72 20 78 20 69 6e 20  |ame(x) for x in |
000000c0  70 61 74 68 73 5d 29 0a                           |paths]).|
000000c8

This is what I see on screen:

OS: Centos (7.6.1810), neovim (0.3.2), and neovim-qt (master)…

What happens when you run pycodestyle sanitise.py from the command line? This could be a problem in the vim intergation.

What happens when you run pycodestyle sanitise.py from the command line? This could be a problem in the vim intergation.

HA! the one thing I did not try. It returns 0, no output whatsoever.

I can’t reproduce this (nor @bsmoliak’s example) on the latest version:

$ pycodestyle --version
2.5.0
$ echo -n "a = 1" > file.py | pycodestyle file.py
file.py:1:6: W292 no newline at end of file