Комментарии 40
Меня тоже двойные кавычки подбешивают в некоторых проектах. Мне кажется, лучше всего базировать стайл-гайд на том, как работает repr() для строк: одиночные кавычки за исключением тех случаев, когда двойные кавычки помогают избежать лишнего ескейпинга. Но уж лучше кривой стайл-гайд, чем никакого.
Двойные кавычки в питоне, наверное, используют те, кто несколько раз нажимает пробел вместо одного таба :) Вспомнилось - https://www.youtube.com/watch?v=AXLoRpKnK8U
Ерундой вы какой-то занимаетесь вместо работы. Что, дедлайн далеко, можно кавычки поперекрашивать?
В 2018 в github black был запрос Single quotes option формата строк, обсуждение было жарким, но закончилось оно лишь введением опции
--skip-string-normalization, позволявшей не трогать формат строк в проверяемом коде.
По моему, единственный правильный способ борьбы с такими принципиальными проектами ("все должны использовать наши правила, либо не использовать наш форматтер, т.к. у нас нашлись серьёзные, с нашей точки зрения, причины именно для таких правил, а также этот выбор исключает споры) - создать форк (назвав его white :) ), который будет полной копией, за исключением правила с кавычками.
Я тут немного ради похоливарить и любопытство потешить. В джаве строка – всегда двойные кавычки, а единичный символьный литерал – одинарные. В груви двойные кавычки делают интерполируюмую GString, а одинарные – просто строку. В баше, кажется, тоже, внутри двойных кавычек $ eval'уируется.
Питоном же я почти не пользовался, да и то 2.7 веткой, когда она ещё жива была. Посему вопрос – а чем плохи двойные кавычки?
Пишу на Питоне больше 10 лет, но тоже удивился и зашел узнать ответ на этот вопрос.
Я использую и те и другие кавычки. Особого предпочтения нет, но чаще всего для имен ключей коллекций и коротких строк или символов использую одинарные. Для вывода какой-то строки, например, в лог я, скорее всего, возьму двойные, но это совсем не принципиально.
Судя по всему, это просто режет глаз кому-то сильно ортодоксальному. Вопрос похож на спор - какой размер табуляции использовать - 3 или 4 символа.
Вопрос не в том, что двойные кавычки чем-то плохи. Вопрос в том, как ввести правила по кавычкам на легаси-проекте, применив их сразу ко всему проекту и сохранив статистические предпочтения. Если бы такое же решил сделать в JavaScript, там eslint с опцией --fix сделал бы все автоматом, какой бы формат кавычек я бы не задал в правилах. Для Python такое решение - black - есть только для двойных кавычек.
Почему вообще нужны правила по кавычкам? Потому что если их не заводить, то по моему опыту периодически в пул-реквестах команды появляются случайные правки кавычек в старом коде. Ребята просто берут и правят все одиночные на двойные или наоборот в каком-то файле или куске файла, без видимых причин, потому что им показалось что так лучше. И с их точки зрения они вообще молодцы, что прибрались в коде, применили правило бой-скаута на деле. Чтобы не занимались этим вместо полезной работы ввожу правила и пусть за этим следит линтер.
Их надо с шифтом вводить
1. Когда набираешь if __name__ == "__main__", с двойными кавычками меньше нажатий/отжатий Shift :)
2. В определённых областях применения — внутри целевых строк одиночные или двойные встречаются сильно чаще. Например, если вы рисуете подстановку строк-литералов в SQL, им требуются одинарные => вокруг надо делать двойные, а если имён объектов (таблиц, колонок) — двойные. (Да, я знаю, что по идеальной норме это всё давно сделано в некотором middleware. Это только для примера специфичной области.)
С другой стороны, тут скорее хочется чего-то в стиле C++ `R«abc(x»y«z»)abc"`, чтобы вообще иметь один универсальный независимый от контента формат квотинга. Ну или хотя бы `qq(x«y»z")`, как в Perl.
3. Редакторы, заточенные под текст, а не код, конвертят (сразу или при генерации выхода) "x" в “x”, причём плюя на локаль (для русского должно было быть „x“). С одинарными кавычками такого не происходит. Иногда это становится важным (сайты статей типа хабра, учебные материалы).
Очевидно же, что двойные кавычки плохи тем, что они распространены в других языках программирования (Python - "клей", часто использует инжекты другого кода). Ну и в современном прагматичном русском двойные кавычки (не елочки, они вредны во всех отношениях) - в названия компаний ООО "Ромашка", в литературе итд. А значит их труднее (чем в одинарных), внедрить и сохранить в строке python без экранирования, а значит правильнее всегда использовать одинарные кавычки (меньше печатать), сравните:
print('ООО "Ромашка"','далее','"исполнитель"')
print("ООО "\"Ромашка\"','далее','\"исполнитель\"') # на +5 больше нажатий клавиш (+10%)
Два варианта кавычек - еще одна киллерфича Питон, за какие его и любят. 10% роста производительности труда/печатания на дороге не валяются. Исключение - обязательное использование тройных двойных """ по PEP8 для docstring функций, это для автодокументирования, будущего парсинга кода для книгоиздателей итп. Ну и просто красиво. Их и набирать не надо - приличная IDE их после def() напечатает сама. Тройные одинарные тоже работают, но читаются хуже.
query = "select * from table where status = 'active'"
Вот вам примеры когда одинарные кавычки внутри текста лучше заключать во внешние двойные.
print("Please enter user's first name:")
А если такой запрос? select * from «Current year subscribers» where «Last status» = 'active'
(и нет, [] не пойдёт, не MS SQL)
> print(«Please enter user's first name:»)
Тут вообще должен быть U+02BC:
print(«Please enter userʼs first name:»)
print('Please enter userʼs first name:')
PS: Я к тому, что есть нюансы:)
Ну тогда эти люди должны ещё больше любить Perl:
$a = '123';
$a = q(123);
$a = q{123};
$a = q!123!;
$a = q*123*;
$a = q 41234;
всё одно и то же. А если заменить q на qq, будет с интерполяцией (как в Питоне f"...").
> Очевидно же, что двойные кавычки плохи тем, что они распространены в других языках программирования
А в SQL мы имеем одинарные для данных и двойные для идентификаторов. И куды бечь…
Меня аргументы black'а убедили.
Сравните: '' + '' и " + "
Одно - пустая строка, второе - плюсик с пробелами.
Игры со шрифтами позволят увидеть разницу '' + '' и " + "
но в общем случае путаница может быть. Так что у них есть валидный аргумент, а т.к. всё остальное вкусовщина, то даже один слабый аргумент побеждает полное отсутствие аргументов.
Вы хотите сказать что бывают такие, кто пишет код не с моноширинным шрифтом? Вот такие на Python я даже не представляю что могут выжить без повреждения мозга.
Даже в моноширинном шрифте они всё равно вызывают неоднозначность, если находятся в середине сложного выражения.
Аргумент есть. А вот у сторонников одинарных кавычек аргументов кроме "мне так нравится" нет.
До аргументации black'а у меня не было оформленного мнения (кроме того, что любого человека из C/Rust бэкграунда корёжит от того, что путают &str и char), а тут появилось. Более того, оно появилось как готовое решение, которому можно просто подчиниться и забыть навсегда этот вопрос.
(повторюсь из соседнего комментария)
Редакторы, заточенные под текст, а не код, конвертят (сразу или при генерации выхода) "x" в “x”, причём плюя на локаль (для русского должно было быть „x“). С одинарными кавычками такого не происходит. Иногда это становится важным (сайты статей типа хабра, учебные материалы). С такими проще всё перевести на одинарные.
Корёжит оба типа.
Самый типографичный сайт для текстов.
У меня там блог без всякого жлобства, да и читаю я там много людей так же, как я и читал их до появления paywall'а.
... Вообще, при чём тут модель монетизации? Вы сказали "корраптят только двойные кавычки", я показал пример сайта, где коррапят оба вида.
для русского должно было быть „x“
Для русского должно быть «х».
Даже если абстрагироваться от того, что пример высосан из пальца, само по себе это бред, не знаю ни одного ЯП, где было бы нормальным использование немоноширинного шрифта. А с Питоном - тут это особенно важно. При публикации кода на веб-ресурсах (в т.ч. на Хабре) принято тоже код моноширинным шрифтом оформлять.
В том треде репозитория black накидали очень много хороших аргументов, почему будет лучше, когда стиль кавычек можно выбрать самому. Хорошо, что мейнтейнер хотя бы добавил skip-string-normalization, а вообще мне показалось, что он отклонил запрос исходя из собственных субъективных предпочтений.
Когда мы у себя внедряли black, я тоже рассматривал вариант с форком (но это сразу показалось сложно и лениво), поэтому в итоге пришли к варианту c pre-commit: т.е. в начале в .pre-commit-config.yaml указан black, потом isort, а потом double-quote-string-fixer (встроенный в pre-commit хук). Works like a charm.
Использую black в своих питонячьих пет-проектах, форматирование включено в стандартный флоу. Один вызов make сначала приведёт стиль в норму, а потом запустит тесты. В общем-то, ради тестов я его обычно и запускаю, а форматирование становится приятным бонусом. Получается так: пишу код как хочу - с одинарными кавычками, длинными строками и т.п. - но на выходе автоматически получается "правильный" код. Ещё до попадания в коммит! Иногда система чуток сбоит (делаю коммит без проверки), но это не особо напрягает.
Все автоматические утилиты имеют свою "цену использования". Чем дальше они от непосредственного момента написания кода, чем дольше работают, и чем больше ставят препонов, тем эта цена выше. Она выражается как в времени разработчика, которое уходит на переделку, так и в "затрачиваемых нервах". С этой точки зрения, black - практически идеальный инструмент, если использовать его правильно. А вот flake я раньше использовал, но со временем выкинул - потому что он постоянно душнил к месту и не к месту, и при этом не предоставлял инструментов для автоматической чистки кода. Другими словами, цена использования оказалась для меня выше, чем приносимый профит.
Массовое форматирование кода - неприятная штука, конечно. Но оно делается один раз на всю кодовую базу, после чего уже можно жить в новом, гораздо более приятном окружении. И не тратить кучу сил на впиливание и дальнейшую поддержку костылей по типу описанных в статье (уж извините).
Вопрос из чистого любопытства (возможно бестолковый) - а чем смесь разных типов кавычек плоха?
На мой взгляд двойные кавычки лучше, потому что их легче заметить в тексте, сильнее в глаз бросаются.
Теперь проблема решается с помощью ruff
Настройки:
[tool.ruff]
select = [..., "Q"]
[tool.ruff.flake8-quotes]
docstring-quotes = "double"
inline-quotes = "single"
multiline-quotes = "double"
avoid-escape = false
Single quotes black