W292 python ошибка

Files should end with a newline.

Anti-pattern

Imagine the example below is an entire file.

import os

BASE_DIR = os.path.dirname(os.path.abspath(__file__))

Best practice

Imagine the example below is an entire file.

import os

BASE_DIR = os.path.dirname(os.path.abspath(__file__))
# This is a new line that ends the file.

I’m having trouble understanding what «No newline at end of file» means exactly.

The error is pointing to the last line

Can someone help explain to me why I’m getting this invalid error and offer a solution to solve it. Thanks

1 Answer 1

It means exactly what it says. There is no recognizable newline at the end of the file. The last character is the ) . or maybe a TAB , or SPACE , or a line terminator for a different platform.

Solution: open the file in an editor, add a newline at the end, save and close the file.

I’ve tried that, I had a new line after it and I get «blank line contains whitespace» error.

So what you had was a line consisting of white space (SPACE or TAB characters) followed by a newline. Use your editor to get rid of that line.

The style checker wants the last line of the file to end with the newline character, and to have no trailing whitespace on that line.

Почему важно всегда ставить символ переноса строки в конце текстовых файлов?

Иногда при просмотре диффов коммитов через git log или git diff можно заметить следующий вывод:

Или на GitHub в интерфейсе для просмотра диффов:

Почему это так важно, что Git и GitHub предупреждают нас об этом? Давайте разберемся.

Что такое символ переноса строки?

Что может быть проще, чем текстовый файл? Просто текстовые данные — как хранятся на диске, так и отображаются. На самом деле правительство нам врёт всё немного сложнее.

Оффтопик про управляющие символы ASCII

Не все символы, которые содержатся в текстовых файлах, имеют визуальное представление. Такие символы ещё называют «управляющими», и к ним относятся, например:

• нулевой символ ( x00 , ) — часто используется для кодирования конца строки в памяти; т.е. программа считывает символы из памяти по одному до тех пор, пока не встретит нулевой символ, и тогда строка считается завершённой;
• табуляция ( x09 , t ) — используется для выравнивания данных по границе столбца, так что это выглядит как таблица;
• перевод строки ( x0a , n ) — используется для разделения текстовых данных на отдельные строки;
• возврат каретки ( x0d , r ) — переместить курсор в начало строки;
• возврат на один символ ( x08 , b ) — переместить курсор на один символ назад;
• звонок ( x07 , a ) — если набрать этот символ в терминале, то будет бибикающий символ; именно так консольные программы, типа vim , бибикают на пользователей; .

Многие эти символы пришли к нам из эпохи печатных машинок, поэтому у них такие странные названия. И действительно, в контексте печатной машинки или принтера такие операции, как перевод строки (сместить лист бумаги вверх так, чтобы печатающая головка попала на следующую строку), возврат каретки (переместить печатающую головку в крайнее левое положение) и возврат на один символ назад, обретают смысл. При помощи возврата на один символ назад создавались жирные символы (печатаешь символ, возвращаешься назад и печатаешь его ещё раз) и буквы с диакритическими знаками, такие как à или ã (печатаешь символ, возвращаешься назад и печатаешь апостроф или тильду). Но зачем печатной машинке бибикалка?

Сегодня многие из этих символов потеряли смысл, но некоторые до сих пор выполняют функцию, схожую с исходной.

Текстовые редакторы отображают текстовые файлы в некоем адаптированном виде, преобразуя непечатаемые символы, например, переносы строк и табуляции преобразуются в настоящие отдельные строки или выравнивающие отступы.

Для набора символа переноса строки достаточно нажать клавишу «Enter», но на разных платформах этот символ закодируется по-разному:

• в Unix-совместимых системах (включая современные версии macOS) используется один символ перевода строки ( LF );
• в Windows используется сразу два символа — возврат каретки ( CR ) и перевод строки ( LF );
• в очень старых версиях Mac OS (до 2001 года) использовался один символ CR .

Как видите, Windows точнее всего эмулирует поведение печатной машинки.

В языках программирования символ новой строки часто кодируют при помощи бэкслэш-последовательностей, таких как n или rn . Нужно понимать разницу между такой последовательностью и настоящим символом переноса строки. Если в редакторе в файле *.txt просто набрать n и сохранить, то вы получите ровно то, что написали. Символом переноса строки оно не станет. Нужно что-то, что заменит эти бэкслэш-последовательности на настоящие символы переноса строки (например, компилятор или интерпретатор языка программирования).

Почему перенос строки в конце файла важен?

Согласно определению из стандарта POSIX, который тоже пришёл к нам из эпохи печатных машинок:

Строка — это последовательность из нуля или более символов, не являющихся символом новой строки, и терминирующего символа новой строки.

Почему важен этот стандарт? Возможен миллиард способов реализовать одно и то же, и только благодаря стандартам, таким как POSIX, мы имеем сейчас огромное количество качественного ПО, которое не конфликтует друг с другом.

Т.е. если вы не ставите символ переноса строки в конце строки, то формально по стандарту такая строка не является валидной. Множество утилит из Unix, которыми я пользуюсь каждый день, написано в согласии с этим стандартом, и они просто не могут правильно обрабатывать такие «сломанные» строки.

Давайте, например, через Python создадим такой файл со сломанными строками:

Сколько по-вашему в этом файле строк? Три? Давайте посмотрим, что об этом файле думает утилита wc , которая с флагом -l умеет считать количество строк в файле:

Упс! wc нашла только 2 строки!

Давайте создадим еще один файл:

И попробуем теперь склеить два созданных файла при помощи утилиты cat :

Название cat — это сокращение от «конкатенация», и никак не связано с котиками. А жаль.

И опять какой-то странный результат! В большинстве случаев это не то, чего вы бы ожидали, но вполне возможны ситуации, когда вам нужен именно такой результат. Именно поэтому утилита cat не может самостоятельно вставлять отсутствующие символы переноса строки, иначе это сделало бы её поведение неконсистентным.

Это только пара примеров, но многие другие утилиты, которые работают с текстом (например, diff , grep , sed ), имеют такие же проблемы. Собственно говоря, это даже не проблемы, а их задокументированное поведение.

Ещё доводы:

• при дозаписи содержимого в конец файла без переноса строки получится некрасивый дифф — будет изменена последняя строка (хотя на ней всего лишь добавился символ переноса);
• файл с переносом строки и без переноса строки — это два разных файла; для diff и git diff единственный способ отобразить разницу между ними — это напечатать сообщение об отсутствии символа переноса строки;
• согласно стандарту языка C (до 2014 года), непустые файлы с исходным кодом должны заканчиваться символом переноса строки.

Настраиваем редактор

Самый простой способ перестать думать о пустых строках и начать жить — это настроить свой текстовый редактор или IDE на автоматическое добавление символа переноса строки в конец файлов:

• PyCharm и другие IDE JetBrains: Settings > Editor > General > Ensure an empty line at the end of a file on Save ;
• VS Code: «files.insertFinalNewline»: true .

Для других редакторов смотрите настройку здесь.

Кстати, если вы пользуетесь форматтером black , то у меня хорошие новости — он всегда добавляет перенос строки в конец всех файлов *.py .

Заключение

Возможно, такая маленькая деталь, как перенос строки в конце файла и не кажется очень важной, а тема вообще кажется спорной, но боюсь, что у нас нет другого выбора, кроме как принять это правило за данность и просто выработать привычку (или настроить инструментарий) всегда ставить символ новой строки в любых текстовых файлах, даже если этого не требуется явно. Это считается распространённой хорошей практикой, и как минимум убережёт вас и ваших коллег от всяких неожиданных эффектов при работе с утилитами Unix.

В текстовом редакторе это выглядит как лишняя пустая строка в конце файла:

W391 blank line at end of file introduces —> W292 no newline at end of file #365

The text was updated successfully, but these errors were encountered:

IanLee1521 commented Jan 3, 2015

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

jkterry1 commented Mar 15, 2018

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

FichteFoll commented Mar 15, 2018 •

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:

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.

hoylemd commented Mar 16, 2018 •

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:

or more concisely:

bsmoliak commented Jan 4, 2019

W391 appears to supercede W292.

Seems like W292 should be raised first.

codypiersall commented Jan 16, 2019

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 .