Одинарные кавычки против двойных кавычек в Python [закрыто]

718

Согласно документации, они в значительной степени взаимозаменяемы. Есть ли стилистическая причина использовать один над другим?

Readonly
источник

Ответы:

525

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

Например:

LIGHT_MESSAGES = {
    'English': "There are %(number_of_lights)s lights.",
    'Pirate':  "Arr! Thar be %(number_of_lights)s lights."
}

def lights_message(language, number_of_lights):
    """Return a language-appropriate string reporting the light count."""
    return LIGHT_MESSAGES[language] % locals()

def is_pirate(message):
    """Return True if the given message sounds piratical."""
    return re.search(r"(?i)(arr|avast|yohoho)!", message) is not None
Уилл Харрис
источник
4
Интересно, я использую их точно так же. Я не помню, чтобы когда-либо читал что-нибудь, чтобы подтолкнуть меня в этом направлении. Я также использую тройные одинарные кавычки для длинной строки, не предназначенной для людей, например, необработанный HTML. Может быть, это как-то связано с английскими правилами цитирования.
Майк
12
Большинство программистов Python кодируют это таким образом. Нет явного правила, но поскольку мы часто читаем код таким образом, это становится привычкой.
e-удовлетворительно
Интересно, действительно ли одинарные кавычки для символьных вещей происходят из ярлыка выражения кавычки в Lisp / Scheme. В любом случае, это интуитивно понятно. Кроме того, друзья, если мы следуем рекомендациям по стилю PEP 8, функции должны называться lights_message () и is_pirate ().
yukondude
8
Я думаю, что Perl сделал различие между строками с одинарными кавычками (без интерполяции) и строками с двойными кавычками (с интерполяцией), и что кодеры Python, возможно, унаследовали эту привычку или никогда не отпускали ее.
Дарен Томас
2
Я использую то же соглашение, плюс злоупотребляю им, когда vim выделяет все в тройных одинарных кавычках как SQL.
RoundTower
96

Цитирование официальных документов по адресу https://docs.python.org/2.0/ref/strings.html :

На простом английском языке: строковые литералы могут быть заключены в одинарные кавычки (') или двойные кавычки (").

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

Конни
источник
3
да, для меня последовательность является ключевой, поэтому я просто использую синглы везде. Меньше нажатий клавиш, однозначных и последовательных.
mlissner
90

Раньше я предпочитал ', особенно для '''docstrings''', как я нахожу """this creates some fluff""". Кроме того, 'можно печатать без Shiftключа на моей швейцарской немецкой клавиатуре.

С тех пор я изменил использование тройных кавычек для """docstrings"""соответствия PEP 257 .

Дарен Томас
источник
2
Я обычно предпочитаю одинарные кавычки, так как я пишу код SQL каждый день, а одинарные кавычки используются для строковых литералов в T-SQL. Но я использую тройные двойные кавычки, потому что строки документации иногда могут использовать в них немного пуха.
эксорцо
4
Использование везде простых кавычек для строк позволяет мне отключать части исходного кода, используя три двойных кавычки - типа '#if 0' и '#endif'.
Дим
12
"требуется клавиша Shift только на QWERTY-клавиатуре ПК. На моей клавиатуре, "на самом деле, легче набирать текст.
Э-Сат
6
на моей клавиатуре "и" оба требуют клавиши Shift.
Loïc Faure-Lacroix
10
Этот ответ противоречит конвенции Python; см. PEP 257, в котором говорится: «Для согласованности всегда используйте« »« тройные двойные кавычки »« »вокруг строк документации. python.org/dev/peps/pep-0257
Buttons840
44

Я с Уиллом:

  • Двойные кавычки для текста
  • Одинарные кавычки для всего, что ведет себя как идентификатор
  • Необработанные строковые литералы в двойных кавычках для регулярных выражений
  • Утроенные двойные кавычки для строк документации

Я буду придерживаться этого, даже если это будет означать побег.

Я получаю наибольшее значение из одинарных кавычек, выделяющихся из-за кавычек. Остальные практики предназначены только для того, чтобы дать этим идентификаторам, заключенным в одинарные кавычки, некоторое место для стояния.

Гарт Кидд
источник
26

Если у вас есть одна строка, то вы должны использовать другую. Например "You're able to do this", или 'He said "Hi!"'. Кроме этого, вы должны быть настолько последовательными, насколько это возможно (внутри модуля, внутри пакета, внутри проекта, внутри организации).

Если ваш код будут читать люди, работающие с C / C ++ (или если вы переключаетесь между этими языками и Python), то использование ''односимвольных и ""более длинных строк может помочь облегчить переход. (Аналогично для следующих других языков, где они не являются взаимозаменяемыми).

Код Python , я видел в дикой природе , как правило , в пользу "более ', но только немного. Единственным исключением является то, что они """these"""встречаются гораздо чаще '''these''', чем я видел.

Тони Мейер
источник
21

Тройной цитаты комментарии являются интересной подтемой этого вопроса. PEP 257 определяет тройные кавычки для строк документа . Я быстро проверил, используя Google Code Search, и обнаружил, что тройные двойные кавычки в Python примерно в 10 раз популярнее, чем тройные одинарные кавычки - 1,3 млн против 131 КБ в коде индексов Google. Так что в случае с несколькими строками ваш код, вероятно, станет более привычным для людей, если он использует тройные двойные кавычки.

jblocksom
источник
13
"If you're going to use apostrophes, 
       ^

you'll definitely want to use double quotes".
   ^

По этой простой причине я всегда использую двойные кавычки снаружи. Всегда

Говоря о пуху, что хорошего в том, чтобы упорядочить ваши строковые литералы с помощью «если вам придется использовать escape-символы для представления апострофов? Обижает ли кодеров читать романы? Я не могу представить, насколько болезненным для вас был урок английского языка в старшей школе!

Droogans
источник
11
«Если вы собираетесь« цитировать »что-то, вы обязательно захотите использовать одинарные кавычки»
Paolo
Мое мнение сильно изменилось с тех пор, как я написал это. Сейчас это просто одна из ситуаций, в которой я бы сказал, что буду использовать двойные кавычки. Другой будет вашим в контексте использования одинарных кавычек. Смотрите принятый ответ для моей текущей позиции по этому вопросу более подробно. Я думаю, что это отличный пример того, как это должно быть представлено широкой аудитории.
Дрооганс
7

Python использует кавычки примерно так:

mystringliteral1="this is a string with 'quotes'"
mystringliteral2='this is a string with "quotes"'
mystringliteral3="""this is a string with "quotes" and more 'quotes'"""
mystringliteral4='''this is a string with 'quotes' and more "quotes"'''
mystringliteral5='this is a string with \"quotes\"'
mystringliteral6='this is a string with \042quotes\042'
mystringliteral6='this is a string with \047quotes\047'

print mystringliteral1
print mystringliteral2
print mystringliteral3
print mystringliteral4
print mystringliteral5
print mystringliteral6

Что дает следующий вывод:

this is a string with 'quotes'
this is a string with "quotes"
this is a string with "quotes" and more 'quotes'
this is a string with 'quotes' and more "quotes"
this is a string with "quotes"
this is a string with 'quotes'
Майкл
источник
2
Но """This is a string with "quotes""""вызывает SyntaxError. Как можно решить эту ситуацию? (так же, как и с '''This is a string with 'quotes'''')
dolma33
1
Вставьте разрыв строки между "цитаты" и "" "
Николас
1
@ dolma33 Предложение Николаса изменило бы содержимое строки. Лучшее решение уже в ответе: если ваша строка заканчивается какой-то кавычкой, используйте другой вид тройной кавычки. Например, '''This is a string with "quotes"'''.
jpmc26
3

Я вообще использую двойные кавычки, но не по какой-то конкретной причине - вероятно, просто по привычке из Java.

Я предполагаю, что вы также скорее всего захотите апострофы в строковой литеральной строке, чем двойные кавычки.

Мэтт Шеппард
источник
3

Лично я придерживаюсь одного или другого. Это не важно А предоставление своего собственного смысла любой цитате просто запутывает других людей, когда вы сотрудничаете.

нейтральный гласный звук
источник
2

Это, вероятно, стилистическое предпочтение больше всего на свете. Я только что проверил PEP 8 и не увидел упоминаний об одинарных и двойных кавычках.

Я предпочитаю одинарные кавычки, потому что это только одно нажатие клавиши вместо двух. То есть мне не нужно нажимать клавишу Shift, чтобы сделать одинарную кавычку.

Майк
источник
1
PEP 8 ссылается на PEP 257 в первом предложении под заголовком «Строки документации». В PEP 257 говорится: «Для согласованности всегда используйте« »« тройные двойные кавычки »« »вокруг строк документации. Используйте r "" "сырые тройные двойные кавычки" "", если вы используете обратную косую черту в ваших строках документов. Для строк документации Unicode используйте u "" "Строки Unicode с тройными кавычками" "". Тем не менее, мне нравится чистый вид одинарной кавычки и одна причина нажатия клавиши, которую вы дали.
maxpolk
2

В Perl вы хотите использовать одинарные кавычки, когда у вас есть строка, которая не нуждается в интерполяции переменных или экранированных символов, таких как \ n, \ t, \ r и т. Д.

PHP делает то же различие, что и Perl: содержимое в одинарных кавычках не будет интерпретироваться (даже \ n не будет преобразовано), в отличие от двойных кавычек, которые могут содержать переменные, для которых выводится их значение.

Боюсь, Python нет. С технической точки зрения, в Python нет $ токена (или тому подобного) для отделения имени / текста от переменной. Обе функции делают Python более читабельным, в конце концов, менее запутанным. Одинарные и двойные кавычки могут использоваться взаимозаменяемо в Python.

Peterino
источник
Для подтверждения того, что вы говорите, \ n будет интерпретироваться только в двойных кавычках в PHP и Perl, тогда как в Python будет работать как в двойных, так и в одинарных кавычках
stivlo
1
@stivlo: Если вы не сделаете из него необработанную строку, добавив rперед строкой литерал. Так print 'a\nb'что напечатает вам две строки, но print r'a\nb'напечатает вам одну.
Tadeck
1

Я решил использовать двойные кавычки, потому что их легче увидеть.

Эндрю Далке
источник
1

Я просто использую то, что поражает мое воображение в то время; удобно переключаться между двумя прихотями!

Конечно, при цитировании цитат characetrs переключение между ними может быть не таким уж и причудливым в конце концов ...


источник
0

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

Если вы находитесь в мультиязычной среде, вы можете поощрять использование кавычек того же типа для строк, которые использует другой язык, например. Иначе мне лично больше всего нравится внешний вид

Винко Врсалович
источник
0

Нет, насколько я знаю. Хотя, если вы посмотрите на некоторый код, «» обычно используется для текстовых строк (я полагаю, «чаще встречается внутри текста, чем»), и «» появляется в хэш-ключах и тому подобном.

Марио Ф
источник
0

Я стремлюсь минимизировать как пиксели, так и удивление. Я обычно предпочитаю 'минимизировать пиксели, но "вместо этого, если строка имеет апостроф, снова минимизировать пиксели. Для строки документации, однако, я предпочитаю """более , '''потому что последний является нестандартным, необычным, и поэтому удивительно. Если сейчас у меня есть несколько строк, которые я использовал в "соответствии с приведенной выше логикой, но также и та, которая может сойти с рук ', я все равно могу использовать "ее для сохранения согласованности, только чтобы минимизировать неожиданность.

Возможно, это помогает думать о философии минимизации пикселей следующим образом. Вы бы предпочли, чтобы английские символы выглядели A B Cили AA BB CC? Последний выбор тратит 50% непустых пикселей.

Акаменус
источник
-1

Я использую двойные кавычки, потому что я делал это годами на большинстве языков (C ++, Java, VB ...), кроме Bash, потому что я также использую двойные кавычки в обычном тексте и потому что я использую (измененную) неанглийскую клавиатуру, где оба символа требуют клавиши Shift.

Philipp
источник
-4

' знак равно "

/= \=\\

пример :

f = open('c:\word.txt', 'r')
f = open("c:\word.txt", "r")
f = open("c:/word.txt", "r")
f = open("c:\\\word.txt", "r")

Результаты одинаковы

= >> нет, они не одинаковы. Единственная обратная косая черта будет экранировать символы. Вы просто случайно повезло в этом примере , потому что \kи \wне являются действительными , как ускользает \tили \nили \\или\"

Если вы хотите использовать одиночные обратные слеши (и интерпретировать их как таковые), вам нужно использовать «необработанную» строку. Вы можете сделать это, поставив ' r' перед строкой

im_raw = r'c:\temp.txt'
non_raw = 'c:\\temp.txt'
another_way = 'c:/temp.txt'

Что касается путей в Windows, косые черты интерпретируются одинаково. Очевидно, что сама строка отличается. Я не гарантирую, что они обрабатываются таким образом на внешнем устройстве.

kn3l
источник
Черт возьми, это старый, но я все равно хотел прокомментировать, чтобы указать, что использование прямой косой черты может работать для окон, но все еще зависит от системы. Чтобы убедиться, что вы свободны от os-зависимостей, используйтеos.path.join()
Adam Smith